All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Namhyung Kim <namhyung@kernel.org>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] libperf: Add API for allocating new thread map
Date: Wed, 16 Feb 2022 10:54:13 -0300	[thread overview]
Message-ID: <Yg0CBc4gEQDX4/WD@kernel.org> (raw)
In-Reply-To: <YguaF9kmFyoZ1ZhC@krava>

Em Tue, Feb 15, 2022 at 01:18:31PM +0100, Jiri Olsa escreveu:
> On Thu, Feb 10, 2022 at 10:52:25AM +0200, Tzvetomir Stoyanov (VMware) wrote:
> > The existing API perf_thread_map__new_dummy() allocates new thread map
> > for one thread. I couldn't find a way to reallocate the map with more
> > threads, or to allocate a new map for more than one thread. Having
> > multiple threads in a thread map is essential for some use cases.
> > That's why a new API is proposed, which allocates a new thread map
> > for given number of threads:
> >  perf_thread_map__new()
> 
> I'm ok with that, just wondering if we should call it 'perf_thread_map__new_nr'
> because we already have perf_cpu_map__new(const char *cpu_list) so
> it might be better to keep perf_cpu_map and perf_thread_map in sync
 
> Arnaldo, thoughts on this?

Agreed on trying to have similar semantics for the default, main
constructor, so we probably need perf_thread_map__new(const char *thread_list).

In tools/perf/util/thread_map.c, from where tools/lib/threadmap.c came
from we have many alternative constructors:

⬢[acme@toolbox perf]$ grep 'struct perf_thread_map \*thread_map__new' tools/perf/util/thread_map.c
struct perf_thread_map *thread_map__new_by_pid(pid_t pid)
struct perf_thread_map *thread_map__new_by_tid(pid_t tid)
struct perf_thread_map *thread_map__new_all_cpus(void)
struct perf_thread_map *thread_map__new_by_uid(uid_t uid)
struct perf_thread_map *thread_map__new(pid_t pid, pid_t tid, uid_t uid)
static struct perf_thread_map *thread_map__new_by_pid_str(const char *pid_str)
struct perf_thread_map *thread_map__new_by_tid_str(const char *tid_str)
struct perf_thread_map *thread_map__new_str(const char *pid, const char *tid,
struct perf_thread_map *thread_map__new_event(struct perf_record_thread_map *event)
⬢[acme@toolbox perf]$

The one you want is almost:

	thread_map__new_by_tid_str(const char *tid_str)

but perhaps it would be better to have:

struct perf_thread_map *thread_map__new_array(int nr_threads, pid_t *array);

But yeah, if your logic needs to first allocate space for the thread_map
and then populate it, make it so that array == NULL is supported for
that case, then thread_map__new_array() will not touch it and set
everything to -1, to be populated later using perf_thread_map__set_pid().

With that thread_map__new_by_tid_str() could be reimplemented as a
wrapper around thread_map__new_array(). :-)

While we're on this, shouldn't we rename 'thread' in
tools/lib/perf/include/perf/threadmap.h and threadmap.c to be 'idx' to
avoid confusion?

- Arnaldo
 
> jirka
> 
> > 
> > Signed-off-by: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
> > ---
> >  tools/lib/perf/Documentation/libperf.txt |  1 +
> >  tools/lib/perf/include/perf/threadmap.h  |  1 +
> >  tools/lib/perf/libperf.map               |  1 +
> >  tools/lib/perf/tests/test-threadmap.c    | 27 ++++++++++++++++++++++++
> >  tools/lib/perf/threadmap.c               | 15 +++++++++----
> >  5 files changed, 41 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/lib/perf/Documentation/libperf.txt b/tools/lib/perf/Documentation/libperf.txt
> > index 32c5051c24eb..9cbd41c29bff 100644
> > --- a/tools/lib/perf/Documentation/libperf.txt
> > +++ b/tools/lib/perf/Documentation/libperf.txt
> > @@ -62,6 +62,7 @@ SYNOPSIS
> >    struct perf_thread_map;
> >  
> >    struct perf_thread_map *perf_thread_map__new_dummy(void);
> > +  struct perf_thread_map *perf_thread_map__new(int nr);
> >  
> >    void perf_thread_map__set_pid(struct perf_thread_map *map, int thread, pid_t pid);
> >    char *perf_thread_map__comm(struct perf_thread_map *map, int thread);
> > diff --git a/tools/lib/perf/include/perf/threadmap.h b/tools/lib/perf/include/perf/threadmap.h
> > index a7c50de8d010..47d433416040 100644
> > --- a/tools/lib/perf/include/perf/threadmap.h
> > +++ b/tools/lib/perf/include/perf/threadmap.h
> > @@ -8,6 +8,7 @@
> >  struct perf_thread_map;
> >  
> >  LIBPERF_API struct perf_thread_map *perf_thread_map__new_dummy(void);
> > +LIBPERF_API struct perf_thread_map *perf_thread_map__new(int nr);
> >  
> >  LIBPERF_API void perf_thread_map__set_pid(struct perf_thread_map *map, int thread, pid_t pid);
> >  LIBPERF_API char *perf_thread_map__comm(struct perf_thread_map *map, int thread);
> > diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
> > index 93696affda2e..240a2f087b70 100644
> > --- a/tools/lib/perf/libperf.map
> > +++ b/tools/lib/perf/libperf.map
> > @@ -11,6 +11,7 @@ LIBPERF_0.0.1 {
> >  		perf_cpu_map__empty;
> >  		perf_cpu_map__max;
> >  		perf_cpu_map__has;
> > +		perf_thread_map__new;
> >  		perf_thread_map__new_dummy;
> >  		perf_thread_map__set_pid;
> >  		perf_thread_map__comm;
> > diff --git a/tools/lib/perf/tests/test-threadmap.c b/tools/lib/perf/tests/test-threadmap.c
> > index 5e2a0291e94c..3388bf36dfc0 100644
> > --- a/tools/lib/perf/tests/test-threadmap.c
> > +++ b/tools/lib/perf/tests/test-threadmap.c
> > @@ -11,9 +11,12 @@ static int libperf_print(enum libperf_print_level level,
> >  	return vfprintf(stderr, fmt, ap);
> >  }
> >  
> > +#define THREADS_NR	5
> > +
> >  int test_threadmap(int argc, char **argv)
> >  {
> >  	struct perf_thread_map *threads;
> > +	int i;
> >  
> >  	__T_START;
> >  
> > @@ -27,6 +30,30 @@ int test_threadmap(int argc, char **argv)
> >  	perf_thread_map__put(threads);
> >  	perf_thread_map__put(threads);
> >  
> > +	threads = perf_thread_map__new(THREADS_NR);
> > +	if (!threads)
> > +		tests_failed++;
> > +
> > +	if (perf_thread_map__nr(threads) != THREADS_NR)
> > +		tests_failed++;
> > +
> > +	for (i = 0; i < THREADS_NR; i++) {
> > +		if (perf_thread_map__pid(threads, i) != -1)
> > +			tests_failed++;
> > +	}
> > +
> > +	for (i = 1; i < THREADS_NR; i++)
> > +		perf_thread_map__set_pid(threads, i, i * 100);
> > +
> > +	if (perf_thread_map__pid(threads, 0) != -1)
> > +		tests_failed++;
> > +
> > +	for (i = 1; i < THREADS_NR; i++) {
> > +		if (perf_thread_map__pid(threads, i) != i * 100)
> > +			tests_failed++;
> > +	}
> > +	perf_thread_map__put(threads);
> > +
> >  	__T_END;
> >  	return tests_failed == 0 ? 0 : -1;
> >  }
> > diff --git a/tools/lib/perf/threadmap.c b/tools/lib/perf/threadmap.c
> > index e92c368b0a6c..843fe1070cc9 100644
> > --- a/tools/lib/perf/threadmap.c
> > +++ b/tools/lib/perf/threadmap.c
> > @@ -42,18 +42,25 @@ char *perf_thread_map__comm(struct perf_thread_map *map, int thread)
> >  	return map->map[thread].comm;
> >  }
> >  
> > -struct perf_thread_map *perf_thread_map__new_dummy(void)
> > +struct perf_thread_map *perf_thread_map__new(int nr)
> >  {
> > -	struct perf_thread_map *threads = thread_map__alloc(1);
> > +	struct perf_thread_map *threads = thread_map__alloc(nr);
> > +	int i;
> >  
> >  	if (threads != NULL) {
> > -		perf_thread_map__set_pid(threads, 0, -1);
> > -		threads->nr = 1;
> > +		for (i = 0; i < nr; i++)
> > +			perf_thread_map__set_pid(threads, i, -1);
> > +		threads->nr = nr;
> >  		refcount_set(&threads->refcnt, 1);
> >  	}
> >  	return threads;
> >  }
> >  
> > +struct perf_thread_map *perf_thread_map__new_dummy(void)
> > +{
> > +	return perf_thread_map__new(1);
> > +}
> > +
> >  static void perf_thread_map__delete(struct perf_thread_map *threads)
> >  {
> >  	if (threads) {
> > -- 
> > 2.34.1
> > 

-- 

- Arnaldo

  reply	other threads:[~2022-02-16 13:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10  8:52 [PATCH] libperf: Add API for allocating new thread map Tzvetomir Stoyanov (VMware)
2022-02-15  4:53 ` Tzvetomir Stoyanov
2022-02-15 12:18 ` Jiri Olsa
2022-02-16 13:54   ` Arnaldo Carvalho de Melo [this message]
2022-02-16 14:44     ` Tzvetomir Stoyanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yg0CBc4gEQDX4/WD@kernel.org \
    --to=acme@kernel.org \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=olsajiri@gmail.com \
    --cc=tz.stoyanov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.