From: James Clark <james.clark@arm.com>
To: Ian Rogers <irogers@google.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
"Jiri Olsa" <jolsa@kernel.org>,
"Namhyung Kim" <namhyung@kernel.org>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Suzuki K Poulose" <suzuki.poulose@arm.com>,
"Mike Leach" <mike.leach@linaro.org>,
"Leo Yan" <leo.yan@linaro.org>,
"John Garry" <john.g.garry@oracle.com>,
"Will Deacon" <will@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Darren Hart" <dvhart@infradead.org>,
"Davidlohr Bueso" <dave@stgolabs.net>,
"André Almeida" <andrealmeid@igalia.com>,
"Kan Liang" <kan.liang@linux.intel.com>,
"K Prateek Nayak" <kprateek.nayak@amd.com>,
"Sean Christopherson" <seanjc@google.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Kajol Jain" <kjain@linux.ibm.com>,
"Athira Rajeev" <atrajeev@linux.vnet.ibm.com>,
"Andrew Jones" <ajones@ventanamicro.com>,
"Alexandre Ghiti" <alexghiti@rivosinc.com>,
"Atish Patra" <atishp@rivosinc.com>,
"Steinar H. Gunderson" <sesse@google.com>,
"Yang Jihong" <yangjihong1@huawei.com>,
"Yang Li" <yang.lee@linux.alibaba.com>,
"Changbin Du" <changbin.du@huawei.com>,
"Sandipan Das" <sandipan.das@amd.com>,
"Ravi Bangoria" <ravi.bangoria@amd.com>,
"Paran Lee" <p4ranlee@gmail.com>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Huacai Chen" <chenhuacai@kernel.org>,
"Yanteng Si" <siyanteng@loongson.cn>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
bpf@vger.kernel.org
Subject: Re: [PATCH v1 06/14] libperf cpumap: Add any, empty and min helpers
Date: Tue, 12 Dec 2023 14:51:34 +0000 [thread overview]
Message-ID: <2cd09e7c-eb88-6726-6169-647dcd0a8101@arm.com> (raw)
In-Reply-To: <63d7fe55-719e-43f8-531c-eb7fa30c473a@arm.com>
On 12/12/2023 14:00, James Clark wrote:
>
>
> On 29/11/2023 06:02, Ian Rogers wrote:
>> Additional helpers to better replace
>> perf_cpu_map__has_any_cpu_or_is_empty.
>>
>> Signed-off-by: Ian Rogers <irogers@google.com>
>> ---
>> tools/lib/perf/cpumap.c | 27 +++++++++++++++++++++++++++
>> tools/lib/perf/include/perf/cpumap.h | 16 ++++++++++++++++
>> tools/lib/perf/libperf.map | 4 ++++
>> 3 files changed, 47 insertions(+)
>>
>> diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
>> index 49fc98e16514..7403819da8fd 100644
>> --- a/tools/lib/perf/cpumap.c
>> +++ b/tools/lib/perf/cpumap.c
>> @@ -316,6 +316,19 @@ bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map)
>> return map ? __perf_cpu_map__cpu(map, 0).cpu == -1 : true;
>> }
>>
>> +bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map)
>> +{
>> + if (!map)
>> + return true;
>> +
>> + return __perf_cpu_map__nr(map) == 1 && __perf_cpu_map__cpu(map, 0).cpu == -1;
>> +}
>> +
>> +bool perf_cpu_map__is_empty(const struct perf_cpu_map *map)
>> +{
>> + return map == NULL;
>> +}
>> +
>
> Maybe it doesn't currently happen, but it seems a bit weird that the
> 'new' function can create a map of length 0 which would return empty ==
> false here.
>
> Could we either make this check also return true for maps with length 0,
> or prevent the new function from returning a map of 0 length?
>
By 'new' I actually meant perf_cpu_map__alloc(). I see
perf_cpu_map__new() actually takes a string, and returns all online CPUs
if the string is null, but similarly I don't see a use case where that
string is NULL.
Having something return either the parsed string, or all online CPUs if
the string was null seems like unnecessary hidden behaviour so it would
be good to remove that one too.
>> int perf_cpu_map__idx(const struct perf_cpu_map *cpus, struct perf_cpu cpu)
>> {
>> int low, high;
>> @@ -372,6 +385,20 @@ bool perf_cpu_map__has_any_cpu(const struct perf_cpu_map *map)
>> return map && __perf_cpu_map__cpu(map, 0).cpu == -1;
>> }
>>
>> +struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map)
>> +{
>> + struct perf_cpu cpu, result = {
>> + .cpu = -1
>> + };
>> + int idx;
>> +
>> + perf_cpu_map__for_each_cpu_skip_any(cpu, idx, map) {
>> + result = cpu;
>> + break;
>> + }
>> + return result;
>> +}
>> +
>> struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map)
>> {
>> struct perf_cpu result = {
>> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
>> index dbe0a7352b64..523e4348fc96 100644
>> --- a/tools/lib/perf/include/perf/cpumap.h
>> +++ b/tools/lib/perf/include/perf/cpumap.h
>> @@ -50,6 +50,22 @@ LIBPERF_API int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
>> * perf_cpu_map__has_any_cpu_or_is_empty - is map either empty or has the "any CPU"/dummy value.
>> */
>> LIBPERF_API bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map);
>> +/**
>> + * perf_cpu_map__is_any_cpu_or_is_empty - is map either empty or the "any CPU"/dummy value.
>> + */
>> +LIBPERF_API bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map);
>> +/**
>> + * perf_cpu_map__is_empty - does the map contain no values and it doesn't
>> + * contain the special "any CPU"/dummy value.
>> + */
>> +LIBPERF_API bool perf_cpu_map__is_empty(const struct perf_cpu_map *map);
>> +/**
>> + * perf_cpu_map__min - the minimum CPU value or -1 if empty or just the "any CPU"/dummy value.
>> + */
>> +LIBPERF_API struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map);
>> +/**
>> + * perf_cpu_map__max - the maximum CPU value or -1 if empty or just the "any CPU"/dummy value.
>> + */
>> LIBPERF_API struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map);
>> LIBPERF_API bool perf_cpu_map__has(const struct perf_cpu_map *map, struct perf_cpu cpu);
>> LIBPERF_API bool perf_cpu_map__equal(const struct perf_cpu_map *lhs,
>> diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
>> index 10b3f3722642..2aa79b696032 100644
>> --- a/tools/lib/perf/libperf.map
>> +++ b/tools/lib/perf/libperf.map
>> @@ -10,6 +10,10 @@ LIBPERF_0.0.1 {
>> perf_cpu_map__nr;
>> perf_cpu_map__cpu;
>> perf_cpu_map__has_any_cpu_or_is_empty;
>> + perf_cpu_map__is_any_cpu_or_is_empty;
>> + perf_cpu_map__is_empty;
>> + perf_cpu_map__has_any_cpu;
>> + perf_cpu_map__min;
>> perf_cpu_map__max;
>> perf_cpu_map__has;
>> perf_thread_map__new_array;
>
next prev parent reply other threads:[~2023-12-12 14:51 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-29 6:01 [PATCH v1 00/14] Clean up libperf cpumap's empty function Ian Rogers
2023-11-29 6:01 ` [PATCH v1 01/14] libperf cpumap: Rename perf_cpu_map__dummy_new Ian Rogers
2023-12-12 11:20 ` James Clark
2023-11-29 6:01 ` [PATCH v1 02/14] libperf cpumap: Rename and prefer sysfs for perf_cpu_map__default_new Ian Rogers
2023-12-12 11:32 ` James Clark
2023-12-12 17:39 ` Arnaldo Carvalho de Melo
2023-12-12 17:52 ` Ian Rogers
2023-11-29 6:02 ` [PATCH v1 03/14] libperf cpumap: Rename perf_cpu_map__empty Ian Rogers
2023-12-12 11:38 ` James Clark
2023-11-29 6:02 ` [PATCH v1 04/14] libperf cpumap: Replace usage of perf_cpu_map__new(NULL) Ian Rogers
2023-12-12 11:44 ` James Clark
2023-11-29 6:02 ` [PATCH v1 05/14] libperf cpumap: Add for_each_cpu that skips the "any CPU" case Ian Rogers
2023-12-12 13:54 ` James Clark
2023-11-29 6:02 ` [PATCH v1 06/14] libperf cpumap: Add any, empty and min helpers Ian Rogers
2023-12-12 14:00 ` James Clark
2023-12-12 14:51 ` James Clark [this message]
2023-12-12 20:02 ` Ian Rogers
2023-12-12 15:06 ` James Clark
2023-12-12 20:27 ` Ian Rogers
2023-12-13 13:48 ` James Clark
2023-11-29 6:02 ` [PATCH v1 07/14] perf arm-spe/cs-etm: Directly iterate CPU maps Ian Rogers
2023-12-12 14:17 ` James Clark
2023-12-12 14:36 ` James Clark
2024-02-01 2:12 ` Ian Rogers
2024-02-01 11:06 ` James Clark
2023-11-29 6:02 ` [PATCH v1 08/14] perf intel-pt/intel-bts: Switch perf_cpu_map__has_any_cpu_or_is_empty use Ian Rogers
2023-11-29 6:02 ` [PATCH v1 09/14] perf cpumap: Clean up use of perf_cpu_map__has_any_cpu_or_is_empty Ian Rogers
2023-12-12 15:10 ` James Clark
2023-11-29 6:02 ` [PATCH v1 10/14] perf top: Avoid repeated function calls Ian Rogers
2023-12-12 15:11 ` James Clark
2023-12-18 20:34 ` Arnaldo Carvalho de Melo
2023-11-29 6:02 ` [PATCH v1 11/14] perf arm64 header: Remove unnecessary CPU map get and put Ian Rogers
2023-12-12 15:13 ` James Clark
2023-11-29 6:02 ` [PATCH v1 12/14] perf stat: Remove duplicate cpus_map_matched function Ian Rogers
2023-12-12 11:28 ` James Clark
2023-11-29 6:02 ` [PATCH v1 13/14] perf cpumap: Use perf_cpu_map__for_each_cpu when possible Ian Rogers
2023-12-12 11:25 ` James Clark
2023-11-29 6:02 ` [PATCH v1 14/14] libperf cpumap: Document perf_cpu_map__nr's behavior Ian Rogers
2023-12-12 15:20 ` James Clark
2023-12-18 20:36 ` Arnaldo Carvalho de Melo
2023-12-11 19:31 ` [PATCH v1 00/14] Clean up libperf cpumap's empty function Ian Rogers
2023-12-12 17:59 ` Arnaldo Carvalho de Melo
2023-12-13 12:48 ` Adrian Hunter
2023-12-14 13:49 ` Arnaldo Carvalho de Melo
2023-12-13 23:29 ` Namhyung Kim
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=2cd09e7c-eb88-6726-6169-647dcd0a8101@arm.com \
--to=james.clark@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ajones@ventanamicro.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexghiti@rivosinc.com \
--cc=andrealmeid@igalia.com \
--cc=atishp@rivosinc.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=bpf@vger.kernel.org \
--cc=changbin.du@huawei.com \
--cc=chenhuacai@kernel.org \
--cc=coresight@lists.linaro.org \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=irogers@google.com \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=kjain@linux.ibm.com \
--cc=kprateek.nayak@amd.com \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=ndesaulniers@google.com \
--cc=p4ranlee@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=sandipan.das@amd.com \
--cc=seanjc@google.com \
--cc=sesse@google.com \
--cc=siyanteng@loongson.cn \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=yang.lee@linux.alibaba.com \
--cc=yangjihong1@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox