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: <20250103224506.185cc746@pumpkin>
Date: Fri, 3 Jan 2025 22:45:06 +0000
From: David Laight <david.laight.linux@...il.com>
To: Leo Yan <leo.yan@....com>
Cc: Ian Rogers <irogers@...gle.com>, 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 v2] perf cpumap: Reduce cpu size from int to int16_t

On Fri, 3 Jan 2025 18:25:32 +0000
Leo Yan <leo.yan@....com> wrote:

> On Fri, Dec 20, 2024 at 10:52:07AM -0800, Ian Rogers wrote:
> > 
> > Fewer than 32k logical CPUs are currently supported by perf. A cpumap
> > is indexed by an integer (see perf_cpu_map__cpu) yielding a perf_cpu
> > that wraps a 4-byte int for the logical CPU - the wrapping is done
> > deliberately to avoid confusing a logical CPU with an index into a
> > cpumap. Using a 4-byte int within the perf_cpu is larger than required
> > so this patch reduces it to the 2-byte int16_t. For a cpumap
> > containing 16 entries this will reduce the array size from 64 to 32
> > bytes. For very large servers with lots of logical CPUs the size
> > savings will be greater.
> > 
> > Signed-off-by: Ian Rogers <irogers@...gle.com>
> > Reviewed-by: Tim Chen <tim.c.chen@...ux.intel.com>
> > ---
> > v2. Rebase and tweak commit message.
> > ---
> >  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 188a667babc6..8c1ab0f9194e 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;  
> 
> I am concerned for the data conversion from int type to int16_t type.
> 
> The GCC option "-Wconversion" is not enabled in perf Makefile, unsafe
> data conversion is allowed.  A better way is to update argument type for
> get_max_num() for reading CPU number with int16_t type.

Or just avoid passing &int_var by using the return value instead.
It'll generate smaller, faster code.

	David


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ