From: Jiri Olsa <olsajiri@gmail.com>
To: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>
Cc: acme@kernel.org, jolsa@redhat.com,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] libperf: Add API for allocating new thread map
Date: Tue, 15 Feb 2022 13:18:31 +0100 [thread overview]
Message-ID: <YguaF9kmFyoZ1ZhC@krava> (raw)
In-Reply-To: <20220210085225.551891-1-tz.stoyanov@gmail.com>
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?
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
>
next prev parent reply other threads:[~2022-02-15 12:18 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 [this message]
2022-02-16 13:54 ` Arnaldo Carvalho de Melo
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=YguaF9kmFyoZ1ZhC@krava \
--to=olsajiri@gmail.com \
--cc=acme@kernel.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--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.