linux-kernel - Re: [PATCH v1] perf cpumap: Reduce cpu size from int to int16

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP-5=fXYQ0ANtpK521jy3vP516+tp42EtKvCJMaK9H1brgB9BA@mail.gmail.com>
Date: Mon, 9 Dec 2024 08:29:04 -0800
From: Ian Rogers <irogers@...gle.com>
To: Leo Yan <leo.yan@....com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, 
	Mark Rutland <mark.rutland@....com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, 
	Adrian Hunter <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>, 
	James Clark <james.clark@...aro.org>, Tim Chen <tim.c.chen@...ux.intel.com>, 
	Yicong Yang <yangyicong@...ilicon.com>, Ravi Bangoria <ravi.bangoria@....com>, 
	linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Kyle Meyer <kyle.meyer@....com>
Subject: Re: [PATCH v1] perf cpumap: Reduce cpu size from int to int16_t

On Mon, Dec 9, 2024 at 12:55 AM Leo Yan <leo.yan@....com> wrote:
>
> 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"?

I'm just trying to say "sizeof(int) == 4" and we have as many of them
as we have logical 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@...gle.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.

The change is done this way as passing an int16_t* to a function
expecting an int* causes compiler warnings.

> If get an error for max present CPU number, should we rollback to 4096
> for both max_cpu_num and max_present_cpu_num?

We could. It is probably safest to keep the existing behavior.

Thanks,
Ian

> 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
> >