On Mon, Dec 13, 2021 at 8:10 AM Ian Rogers [off-list ref] wrote:

On Mon, Dec 13, 2021 at 3:39 AM James Clark [off-list ref] wrote:

quoted

On 08/12/2021 02:45, Ian Rogers wrote:

quoted

Perf cpu map has various functions where a cpumap and index are passed
in order to load the cpu. A problem with this is that the wrong index
may be passed for the cpumap, causing problems like aggregation on the
wrong CPU:
https://lore.kernel.org/lkml/20211204023409.969668-1-irogers@google.com/ (local)

This patch set refactors the cpu map API, greatly reducing it and
explicitly passing the cpu (rather than the pair) to functions that
need it. Comments are added at the same time.

Ian Rogers (22):
  libperf: Add comments to perf_cpu_map.
  perf stat: Add aggr creators that are passed a cpu.
  perf stat: Switch aggregation to use for_each loop
  perf stat: Switch to cpu version of cpu_map__get
  perf cpumap: Switch cpu_map__build_map to cpu function
  perf cpumap: Remove map+index get_socket
  perf cpumap: Remove map+index get_die
  perf cpumap: Remove map+index get_core
  perf cpumap: Remove map+index get_node
  perf cpumap: Add comments to aggr_cpu_id
  perf cpumap: Remove unused cpu_map__socket
  perf cpumap: Simplify equal function name.
  perf cpumap: Rename empty functions.
  perf cpumap: Document cpu__get_node and remove redundant function
  perf cpumap: Remove map from function names that don't use a map.
  perf cpumap: Remove cpu_map__cpu, use libperf function.
  perf cpumap: Refactor cpu_map__build_map
  perf cpumap: Rename cpu_map__get_X_aggr_by_cpu functions
  perf cpumap: Move 'has' function to libperf
  perf cpumap: Add some comments to cpu_aggr_map
  perf cpumap: Trim the cpu_aggr_map
  perf stat: Fix memory leak in check_per_pkg

 tools/lib/perf/cpumap.c                  |   7 +-
 tools/lib/perf/include/internal/cpumap.h |   9 +-
 tools/lib/perf/include/perf/cpumap.h     |   1 +
 tools/perf/arch/arm/util/cs-etm.c        |  16 +-
 tools/perf/builtin-ftrace.c              |   2 +-
 tools/perf/builtin-sched.c               |   6 +-
 tools/perf/builtin-stat.c                | 273 ++++++++++++-----------
 tools/perf/tests/topology.c              |  10 +-
 tools/perf/util/cpumap.c                 | 182 ++++++---------
 tools/perf/util/cpumap.h                 | 102 ++++++---
 tools/perf/util/cputopo.c                |   2 +-
 tools/perf/util/env.c                    |   6 +-
 tools/perf/util/stat-display.c           |  69 +++---
 tools/perf/util/stat.c                   |   9 +-
 tools/perf/util/stat.h                   |   3 +-
 15 files changed, 361 insertions(+), 336 deletions(-)

For the whole set:

Reviewed-by: James Clark <redacted>

I didn't see any obvious issues with mixing up aggregation modes or CPU/idx types. Also
gave perf stat a test in the different modes and didn't see an issue.

But I'm wondering if it's possible to go further and add a struct around the CPU int so that the
compiler checks for correctness instead. It still seems quite easy to mix up index and
CPU, for example these functions are subtly different, but both use int:

  LIBPERF_API int perf_cpu_map__cpu(const struct perf_cpu_map *cpus, int idx);
  LIBPERF_API bool perf_cpu_map__has(const struct perf_cpu_map *map, int cpu);

Something like this would make it impossible to make a mistake:

  struct cpu { int cpu };

I mean it's more of a coincidence that CPUs can be identified by an integer, but they are more
of an object than an integer, so it could make sense to wrap it. But maybe it could be quite
cumbersome to use and be overkill.

Thanks James! I am working on a v2 patch set and will have a go at
adding this to the end.

Ian

I was checking on the style issues around wrapping an int with a
struct, and it is preferred style to enforce strict type checking (by
way of an old post):
https://lore.kernel.org/all/ancug3$iq1$1@penguin.transmeta.com/ (local)

Thanks,
Ian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel