From: Leo Yan <leo.yan@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>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
James Clark <james.clark@linaro.org>,
Tim Chen <tim.c.chen@linux.intel.com>,
Yicong Yang <yangyicong@hisilicon.com>,
Ravi Bangoria <ravi.bangoria@amd.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Kyle Meyer <kyle.meyer@hpe.com>
Subject: Re: [PATCH v1] perf cpumap: Reduce cpu size from int to int16_t
Date: Mon, 9 Dec 2024 08:55:24 +0000 [thread overview]
Message-ID: <20241209085524.GC5430@e132581.arm.com> (raw)
In-Reply-To: <20241207052133.102829-1-irogers@google.com>
Hi Ian,
On Fri, Dec 06, 2024 at 09:21:33PM -0800, Ian Rogers wrote:
>
> Fewer than 32k CPUs are currently supported by perf. A cpumap stores
> an int per CPU, so its size is 4 times the number of CPUs in the
> cpumap.
Maybe I have a stupid question. An int value has 4 bytes, on the other
hand, we needs 2 bytes to store a 32k value (even 4096 needs 2 bytes
for storing the value).
How can conclude "its size is 4 times the number of CPUs"?
> We can reduce the size of the int to an int16_t, saving 2
> bytes per CPU in the map.
>
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/lib/perf/include/perf/cpumap.h | 3 ++-
> tools/perf/util/cpumap.c | 13 ++++++++-----
> tools/perf/util/env.c | 2 +-
> 3 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> index cbb65e55fc67..760a9aae9884 100644
> --- a/tools/lib/perf/include/perf/cpumap.h
> +++ b/tools/lib/perf/include/perf/cpumap.h
> @@ -4,10 +4,11 @@
>
> #include <perf/core.h>
> #include <stdbool.h>
> +#include <stdint.h>
>
> /** A wrapper around a CPU to avoid confusion with the perf_cpu_map's map's indices. */
> struct perf_cpu {
> - int cpu;
> + int16_t cpu;
> };
>
> struct perf_cache {
> diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
> index 27094211edd8..85e224d8631b 100644
> --- a/tools/perf/util/cpumap.c
> +++ b/tools/perf/util/cpumap.c
> @@ -427,7 +427,7 @@ static void set_max_cpu_num(void)
> {
> const char *mnt;
> char path[PATH_MAX];
> - int ret = -1;
> + int max, ret = -1;
>
> /* set up default */
> max_cpu_num.cpu = 4096;
> @@ -444,10 +444,12 @@ static void set_max_cpu_num(void)
> goto out;
> }
>
> - ret = get_max_num(path, &max_cpu_num.cpu);
> + ret = get_max_num(path, &max);
> if (ret)
> goto out;
>
> + max_cpu_num.cpu = max;
> +
> /* get the highest present cpu number for a sparse allocation */
> ret = snprintf(path, PATH_MAX, "%s/devices/system/cpu/present", mnt);
> if (ret >= PATH_MAX) {
> @@ -455,8 +457,9 @@ static void set_max_cpu_num(void)
> goto out;
> }
>
> - ret = get_max_num(path, &max_present_cpu_num.cpu);
> -
> + ret = get_max_num(path, &max);
> + if (!ret)
> + max_present_cpu_num.cpu = max;
This is an improvement for max CPU number, but it is irrevelant to
changing the CPU type to int16_t. It is better to split it into a new
patch.
If get an error for max present CPU number, should we rollback to 4096
for both max_cpu_num and max_present_cpu_num?
Thanks,
Leo
> out:
> if (ret)
> pr_err("Failed to read max cpus, using default of %d\n", max_cpu_num.cpu);
> @@ -606,7 +609,7 @@ size_t cpu_map__snprint(struct perf_cpu_map *map, char *buf, size_t size)
> #define COMMA first ? "" : ","
>
> for (i = 0; i < perf_cpu_map__nr(map) + 1; i++) {
> - struct perf_cpu cpu = { .cpu = INT_MAX };
> + struct perf_cpu cpu = { .cpu = INT16_MAX };
> bool last = i == perf_cpu_map__nr(map);
>
> if (!last)
> diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c
> index e2843ca2edd9..f1d7d22e7e98 100644
> --- a/tools/perf/util/env.c
> +++ b/tools/perf/util/env.c
> @@ -531,7 +531,7 @@ int perf_env__numa_node(struct perf_env *env, struct perf_cpu cpu)
>
> for (i = 0; i < env->nr_numa_nodes; i++) {
> nn = &env->numa_nodes[i];
> - nr = max(nr, perf_cpu_map__max(nn->map).cpu);
> + nr = max(nr, (int)perf_cpu_map__max(nn->map).cpu);
> }
>
> nr++;
> --
> 2.47.0.338.g60cca15819-goog
>
next prev parent reply other threads:[~2024-12-09 8:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-07 5:21 [PATCH v1] perf cpumap: Reduce cpu size from int to int16_t Ian Rogers
2024-12-09 8:55 ` Leo Yan [this message]
2024-12-09 16:29 ` Ian Rogers
2024-12-09 18:16 ` Tim Chen
2024-12-20 18:32 ` Ian Rogers
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=20241209085524.GC5430@e132581.arm.com \
--to=leo.yan@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=kyle.meyer@hpe.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=tim.c.chen@linux.intel.com \
--cc=yangyicong@hisilicon.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