perf_cpu_map__merge() has two arguments, 'orig' and 'other', as
described in its original comment:

"orig either gets freed and replaced with a new map, or reused
with no reference count change (similar to "realloc")
other has its reference count increased."

This causes confusion due to the different reference counting on the CPU
map objects, which complicates its usage and makes maintenance
difficult. We also discussed this in the email [1].

This patch series makes that a new CPU map is allocated for the
merging result, or the reference count is increased if an existing CPU
map is reused. This means that once perf_cpu_map__merge() is invoked,
the caller gains ownership of the resulting map and must release it
with perf_cpu_map__put().

The perf test has been updated accordingly. Tested result is:

  # ./perf test 41
   41: CPU map                            :
   41.1: Synthesize cpu map               : Ok
   41.2: Print cpu map                    : Ok
   41.3: Merge cpu map                    : Ok
   41.4: Intersect cpu map                : Ok
   41.5: Equal cpu map                    : Ok

[1] https://lore.kernel.org/linux-perf-users/3f03541e-6dab-472f-bad9-4cdc0c0dc061@intel.com/


Leo Yan (5):
  libperf cpumap: Correct reference count for perf_cpu_map__merge()
  perf: Release old CPU maps after merging
  perf cpumap: Update CPU map merging test
  perf cpumap: Add more tests for CPU map merging
  perf cpumap: Add checking for reference counter

 tools/lib/perf/cpumap.c      | 11 ++------
 tools/lib/perf/evlist.c      |  4 +++
 tools/perf/tests/cpumap.c    | 55 ++++++++++++++++++++++++++++++++----
 tools/perf/util/mem-events.c |  4 ++-
 4 files changed, 60 insertions(+), 14 deletions(-)

-- 
2.34.1

On 9/25/24 20:53, Leo Yan wrote:
> perf_cpu_map__merge() has two arguments, 'orig' and 'other', as
> described in its original comment:
> 
> "orig either gets freed and replaced with a new map, or reused
> with no reference count change (similar to "realloc")
> other has its reference count increased."
> 
> This causes confusion due to the different reference counting on the CPU
> map objects, which complicates its usage and makes maintenance
> difficult. We also discussed this in the email [1].
> 
> This patch series makes that a new CPU map is allocated for the
> merging result, or the reference count is increased if an existing CPU
> map is reused. This means that once perf_cpu_map__merge() is invoked,
> the caller gains ownership of the resulting map and must release it
> with perf_cpu_map__put().

Gentle ping ...

Thanks,
Leo

On Thu, Oct 10, 2024 at 04:01:21PM +0100, Leo Yan wrote:
> On 9/25/24 20:53, Leo Yan wrote:
> > perf_cpu_map__merge() has two arguments, 'orig' and 'other', as
> > described in its original comment:
> > 
> > "orig either gets freed and replaced with a new map, or reused
> > with no reference count change (similar to "realloc")
> > other has its reference count increased."
> > 
> > This causes confusion due to the different reference counting on the CPU
> > map objects, which complicates its usage and makes maintenance
> > difficult. We also discussed this in the email [1].
> > 
> > This patch series makes that a new CPU map is allocated for the
> > merging result, or the reference count is increased if an existing CPU
> > map is reused. This means that once perf_cpu_map__merge() is invoked,
> > the caller gains ownership of the resulting map and must release it
> > with perf_cpu_map__put().
> 
> Gentle ping ...

Ian and Adrian, can you please review this patchset?

Thanks,
Namhyung