kernel/tools/lib/perf/cpumap.c, branch linux-rolling-stable

libperf cpumap: Fix perf_cpu_map__max for an empty/NULL map

2025-12-04T08:36:14Z

Passing an empty map to perf_cpu_map__max triggered a SEGV. Explicitly test for the empty map. Reported-by: Ingo Molnar Closes: https://lore.kernel.org/linux-perf-users/aSwt7yzFjVJCEmVp@gmail.com/ Tested-by: Ingo Molnar Signed-off-by: Ian Rogers Tested-by: Thomas Richter Signed-off-by: Namhyung Kim

libperf cpumap: Reduce allocations and sorting in intersect

2025-11-18T02:43:08Z

On hybrid platforms the CPU maps are often disjoint. Rather than copy CPUs and trim, compute the number of common CPUs, if none early exit, otherwise copy in an sorted order. This avoids memory allocation in the disjoint case and avoids a second malloc and useless sort in the previous trim cases. Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim

libperf cpumap: Add ability to create CPU from a single CPU number

2025-05-12T17:18:16Z

Add perf_cpu_map__new_int() so that a CPU map can be created from a single integer. Signed-off-by: Ian Rogers Tested-by: Kan Liang Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Dominique Martinet Cc: Greg Kroah-Hartman Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Leo Yan Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Weilin Wang Cc: Yicong Yang Link: https://lore.kernel.org/r/20250403194337.40202-2-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

perf cpumap: Reduce cpu size from int to int16_t

2025-02-27T16:47:25Z

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 Reviewed-by: James Clark Link: https://lore.kernel.org/r/20250210191231.156294-1-irogers@google.com Signed-off-by: Namhyung Kim

libperf cpumap: Grow array of read CPUs in smaller increments

2024-12-09T20:52:41Z

Instead of growing the array by 2048, grow by the larger of the current range or 16. As ranges are typical for things like the online CPUs this will mean a single allocation happens. While uncore CPU maps will grow 16 at a time which is a value that is generous except say on large servers. Reviewed-by: Leo Yan Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ben Gainey Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Kyle Meyer Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241206044035.1062032-9-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

libperf cpumap: Remove perf_cpu_map__read()

2024-12-09T20:52:41Z

Function is no longer used and duplicates the parsing logic from perf_cpu_map__new(). Remove to allow simplification. Reviewed-by: Leo Yan Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ben Gainey Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Kyle Meyer Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241206044035.1062032-8-irogers@google.com [ Applied manually to cope with "libperf cpumap: Refactor perf_cpu_map__merge()" ] Signed-off-by: Arnaldo Carvalho de Melo

libperf cpumap: Remove use of perf_cpu_map__read()

2024-12-09T20:52:41Z

Remove use of a FILE and switch to reading a string that is then passed to perf_cpu_map__new(). Being able to remove perf_cpu_map__read() avoids duplicated parsing logic. Reviewed-by: Leo Yan Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ben Gainey Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Kyle Meyer Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241206044035.1062032-7-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

libperf cpumap: Be tolerant of newline at the end of a cpumask

2024-12-09T20:52:41Z

File cpumasks often have a newline that shouldn't trigger the invalid parsing case in perf_cpu_map__new(). Reviewed-by: Leo Yan Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ben Gainey Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Kyle Meyer Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241206044035.1062032-5-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

libperf cpumap: Hide/reduce scope of MAX_NR_CPUS

2024-12-09T20:52:41Z

Avoid redefinition of MAX_NR_CPUS as a global constant, the original definition is tools/perf/perf.h. Reviewed-by: Leo Yan Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ben Gainey Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Kyle Meyer Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241206044035.1062032-4-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

libperf cpumap: Refactor perf_cpu_map__merge()

2024-12-09T20:52:41Z

The perf_cpu_map__merge() function has two arguments, 'orig' and 'other'. The function definition might cause confusion as it could give the impression that the CPU maps in the two arguments are copied into a new allocated structure, which is then returned as the result. The purpose of the function is to merge the CPU map 'other' into the CPU map 'orig'. This commit changes the 'orig' argument to a pointer to pointer, so the new result will be updated into 'orig'. The return value is changed to an int type, as an error number or 0 for success. Update callers and tests for the new function definition. Reviewed-by: Adrian Hunter Signed-off-by: Leo Yan Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Ian Rogers Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Link: https://lore.kernel.org/r/20241107125308.41226-2-leo.yan@arm.com Signed-off-by: Arnaldo Carvalho de Melo