All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Leo Yan <leo.yan@arm.com>
Cc: Ian Rogers <irogers@google.com>,
	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 v2] perf cpumap: Reduce cpu size from int to int16_t
Date: Fri, 3 Jan 2025 22:45:06 +0000	[thread overview]
Message-ID: <20250103224506.185cc746@pumpkin> (raw)
In-Reply-To: <20250103182532.GB781381@e132581.arm.com>

On Fri, 3 Jan 2025 18:25:32 +0000
Leo Yan <leo.yan@arm.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@google.com>
> > Reviewed-by: Tim Chen <tim.c.chen@linux.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


  reply	other threads:[~2025-01-03 22:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-20 18:52 [PATCH v2] perf cpumap: Reduce cpu size from int to int16_t Ian Rogers
2025-01-03 18:25 ` Leo Yan
2025-01-03 22:45   ` David Laight [this message]
2025-01-06 18:01     ` 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=20250103224506.185cc746@pumpkin \
    --to=david.laight.linux@gmail.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=leo.yan@arm.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 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.