Re: [PATCH v1 04/12] perf parse-events: Allow the cpu term to be a PMU

[Namhyung Kim <namhyung@kernel.org>]

Hi Ian,

On Wed, Jul 16, 2025 at 01:25:17PM -0700, Ian Rogers wrote:
> On Wed, Jul 16, 2025 at 1:09 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > On Fri, Jun 27, 2025 at 12:24:09PM -0700, Ian Rogers wrote:
> > > On hybrid systems, events like msr/tsc/ will aggregate counts across
> > > all CPUs. Often metrics only want a value like msr/tsc/ for the cores
> > > on which the metric is being computed. Listing each CPU with terms
> > > cpu=0,cpu=1.. is laborious and would need to be encoded for all
> > > variations of a CPU model.
> > >
> > > Allow the cpumask from a PMU to be an argument to the cpu term. For
> > > example in the following the cpumask of the cstate_pkg PMU selects the
> > > CPUs to count msr/tsc/ counter upon:
> > > ```
> > > $ cat /sys/bus/event_source/devices/cstate_pkg/cpumask
> > > 0
> > > $ perf stat -A -e 'msr/tsc,cpu=cstate_pkg/' -a sleep 0.1
> >
> > It can be confusing if 'cpu' takes a number or a PMU name.  What about
> > adding a new term (maybe 'cpu_from') to handle this case?
> 
> So it is possible for terms to be defined in sysfs in the 'format/' folder:
> ```
> $ ls /sys/bus/event_source/devices/cpu_core/format/
> cmask  edge  event  frontend  inv  ldlat  offcore_rsp  pc  umask
> ```
> By not introducing a new term we leave 'cpu_from' open for use in this
> way. When I spoke to Kan we thought using the existing term made sense
> and fits the idea of leaving things open for the kernel/drivers to
> use. It is possible to add a new term though. Let me know and I can
> update the patch and documentation accordingly.

Oh, you thought about this already.  It's true that it's possible to
clash with PMU formats in sysfs unless we have a separate namespace for
tools somehow.  But that would add (maybe unnecessary) complexity.

So I'm not against with this change.  I just wanted to ring an alarm for
potential issues.  Up to you. :)

Thanks,
Namhyung