arch/x86/events/intel/cstate.c | 140 +------------------------- arch/x86/events/rapl.c | 119 ++++++---------------- drivers/dma/idxd/idxd.h | 7 -- drivers/dma/idxd/init.c | 3 - drivers/dma/idxd/perfmon.c | 98 +----------------- drivers/iommu/intel/iommu.h | 2 - drivers/iommu/intel/perfmon.c | 111 +-------------------- include/linux/cpuhotplug.h | 3 - include/linux/perf_event.h | 21 ++++ kernel/events/core.c | 176 ++++++++++++++++++++++++++++++++- 10 files changed, 229 insertions(+), 451 deletions(-)
From: Kan Liang <kan.liang@linux.intel.com>
The perf subsystem assumes that the counters of a PMU are per-CPU. So
the user space tool reads a counter from each CPU in the system wide
mode. However, many PMUs don't have a per-CPU counter. The counter is
effective for a scope, e.g., a die or a socket. To address this, a
cpumask is exposed by the kernel driver to restrict to one CPU to stand
for a specific scope. In case the given CPU is removed,
the hotplug support has to be implemented for each such driver.
The codes to support the cpumask and hotplug are very similar.
- Expose a cpumask into sysfs
- Pickup another CPU in the same scope if the given CPU is removed.
- Invoke the perf_pmu_migrate_context() to migrate to a new CPU.
- In event init, always set the CPU in the cpumask to event->cpu
- Usually, an event can be read from any CPU of the scope. (For now,
it is only supported by the pkg scope PMU, via
PERF_EV_CAP_READ_ACTIVE_PKG, e.g., cstate_pkg, rapl, etc)
Similar duplicated codes are implemented for each such PMU driver. It
would be good to introduce a generic infrastructure to avoid such
duplication.
The patch series introduce 5 popular scopes, core, die, cluster, pkg,
and the system-wide. The PMU drivers for cstate, iommu, idxd and rapl
are updated to apply the new infrastructure. The new infrastructure
can also be applied for other PMU drivers from different ARCHs as well.
But I don't have such platforms. It's not done in this patch series.
They can be added later separately.
The uncore driver isn't updated either. Because a per-PMU cpumask is
required since commit c74443d92f68 ("perf/x86/uncore: Support per PMU
cpumask"). Since different types of PMU share the same hotplug codes,
more factor out works and verification are expected. The cleanup of the
uncore driver can be done later separately.
Kan Liang (7):
perf: Generic hotplug support for a PMU with a scope
perf: Add PERF_EV_CAP_READ_SCOPE
perf/x86/intel/cstate: Clean up cpumask and hotplug
iommu/vt-d: Clean up cpumask and hotplug
dmaengine: idxd: Clean up cpumask and hotplug
perf/x86/rapl: Move the pmu allocation out of CPU hotplug
perf/x86/rapl: Clean up cpumask and hotplug
arch/x86/events/intel/cstate.c | 140 +-------------------------
arch/x86/events/rapl.c | 119 ++++++----------------
drivers/dma/idxd/idxd.h | 7 --
drivers/dma/idxd/init.c | 3 -
drivers/dma/idxd/perfmon.c | 98 +-----------------
drivers/iommu/intel/iommu.h | 2 -
drivers/iommu/intel/perfmon.c | 111 +--------------------
include/linux/cpuhotplug.h | 3 -
include/linux/perf_event.h | 21 ++++
kernel/events/core.c | 176 ++++++++++++++++++++++++++++++++-
10 files changed, 229 insertions(+), 451 deletions(-)
--
2.38.1
Hi Peter,
Gentle ping.
The patch set provides a generic hotplug support to facilitate various
specific PMU drivers. Could you please take a look?
Thanks,
Kan
On 2024-08-02 11:16 a.m., kan.liang@linux.intel.com wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
>
> The perf subsystem assumes that the counters of a PMU are per-CPU. So
> the user space tool reads a counter from each CPU in the system wide
> mode. However, many PMUs don't have a per-CPU counter. The counter is
> effective for a scope, e.g., a die or a socket. To address this, a
> cpumask is exposed by the kernel driver to restrict to one CPU to stand
> for a specific scope. In case the given CPU is removed,
> the hotplug support has to be implemented for each such driver.
>
> The codes to support the cpumask and hotplug are very similar.
> - Expose a cpumask into sysfs
> - Pickup another CPU in the same scope if the given CPU is removed.
> - Invoke the perf_pmu_migrate_context() to migrate to a new CPU.
> - In event init, always set the CPU in the cpumask to event->cpu
> - Usually, an event can be read from any CPU of the scope. (For now,
> it is only supported by the pkg scope PMU, via
> PERF_EV_CAP_READ_ACTIVE_PKG, e.g., cstate_pkg, rapl, etc)
>
> Similar duplicated codes are implemented for each such PMU driver. It
> would be good to introduce a generic infrastructure to avoid such
> duplication.
>
> The patch series introduce 5 popular scopes, core, die, cluster, pkg,
> and the system-wide. The PMU drivers for cstate, iommu, idxd and rapl
> are updated to apply the new infrastructure. The new infrastructure
> can also be applied for other PMU drivers from different ARCHs as well.
> But I don't have such platforms. It's not done in this patch series.
> They can be added later separately.
>
> The uncore driver isn't updated either. Because a per-PMU cpumask is
> required since commit c74443d92f68 ("perf/x86/uncore: Support per PMU
> cpumask"). Since different types of PMU share the same hotplug codes,
> more factor out works and verification are expected. The cleanup of the
> uncore driver can be done later separately.
>
> Kan Liang (7):
> perf: Generic hotplug support for a PMU with a scope
> perf: Add PERF_EV_CAP_READ_SCOPE
> perf/x86/intel/cstate: Clean up cpumask and hotplug
> iommu/vt-d: Clean up cpumask and hotplug
> dmaengine: idxd: Clean up cpumask and hotplug
> perf/x86/rapl: Move the pmu allocation out of CPU hotplug
> perf/x86/rapl: Clean up cpumask and hotplug
>
> arch/x86/events/intel/cstate.c | 140 +-------------------------
> arch/x86/events/rapl.c | 119 ++++++----------------
> drivers/dma/idxd/idxd.h | 7 --
> drivers/dma/idxd/init.c | 3 -
> drivers/dma/idxd/perfmon.c | 98 +-----------------
> drivers/iommu/intel/iommu.h | 2 -
> drivers/iommu/intel/perfmon.c | 111 +--------------------
> include/linux/cpuhotplug.h | 3 -
> include/linux/perf_event.h | 21 ++++
> kernel/events/core.c | 176 ++++++++++++++++++++++++++++++++-
> 10 files changed, 229 insertions(+), 451 deletions(-)
>
On Wed, Sep 04, 2024 at 08:44:47AM -0400, Liang, Kan wrote: > Hi Peter, > > Gentle ping. > > The patch set provides a generic hotplug support to facilitate various > specific PMU drivers. Could you please take a look? Seems nice, still applied, so I've queued it up for the robots to pass judgement.
On 2024-09-06 11:17 a.m., Peter Zijlstra wrote: > On Wed, Sep 04, 2024 at 08:44:47AM -0400, Liang, Kan wrote: >> Hi Peter, >> >> Gentle ping. >> >> The patch set provides a generic hotplug support to facilitate various >> specific PMU drivers. Could you please take a look? > > Seems nice, still applied, so I've queued it up for the robots to pass > judgement. Thanks! Kan
On Fri, Aug 02, 2024 at 08:16:36AM -0700, kan.liang@linux.intel.com wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
>
> The perf subsystem assumes that the counters of a PMU are per-CPU. So
> the user space tool reads a counter from each CPU in the system wide
> mode. However, many PMUs don't have a per-CPU counter. The counter is
> effective for a scope, e.g., a die or a socket. To address this, a
> cpumask is exposed by the kernel driver to restrict to one CPU to stand
> for a specific scope. In case the given CPU is removed,
> the hotplug support has to be implemented for each such driver.
>
> The codes to support the cpumask and hotplug are very similar.
> - Expose a cpumask into sysfs
> - Pickup another CPU in the same scope if the given CPU is removed.
> - Invoke the perf_pmu_migrate_context() to migrate to a new CPU.
> - In event init, always set the CPU in the cpumask to event->cpu
> - Usually, an event can be read from any CPU of the scope. (For now,
> it is only supported by the pkg scope PMU, via
> PERF_EV_CAP_READ_ACTIVE_PKG, e.g., cstate_pkg, rapl, etc)
>
> Similar duplicated codes are implemented for each such PMU driver. It
> would be good to introduce a generic infrastructure to avoid such
> duplication.
>
> The patch series introduce 5 popular scopes, core, die, cluster, pkg,
> and the system-wide. The PMU drivers for cstate, iommu, idxd and rapl
> are updated to apply the new infrastructure. The new infrastructure
> can also be applied for other PMU drivers from different ARCHs as well.
> But I don't have such platforms. It's not done in this patch series.
> They can be added later separately.
>
> The uncore driver isn't updated either. Because a per-PMU cpumask is
> required since commit c74443d92f68 ("perf/x86/uncore: Support per PMU
> cpumask"). Since different types of PMU share the same hotplug codes,
> more factor out works and verification are expected. The cleanup of the
> uncore driver can be done later separately.
>
> Kan Liang (7):
> perf: Generic hotplug support for a PMU with a scope
> perf: Add PERF_EV_CAP_READ_SCOPE
> perf/x86/intel/cstate: Clean up cpumask and hotplug
> iommu/vt-d: Clean up cpumask and hotplug
> dmaengine: idxd: Clean up cpumask and hotplug
> perf/x86/rapl: Move the pmu allocation out of CPU hotplug
> perf/x86/rapl: Clean up cpumask and hotplug
>
> arch/x86/events/intel/cstate.c | 140 +-------------------------
> arch/x86/events/rapl.c | 119 ++++++----------------
Looks like we have another RAPL driver in:
drivers/powercap/intel_rapl_common.c
that wants to be converted.
On 2024-09-06 11:12 a.m., Peter Zijlstra wrote:
> On Fri, Aug 02, 2024 at 08:16:36AM -0700, kan.liang@linux.intel.com wrote:
>> From: Kan Liang <kan.liang@linux.intel.com>
>>
>> The perf subsystem assumes that the counters of a PMU are per-CPU. So
>> the user space tool reads a counter from each CPU in the system wide
>> mode. However, many PMUs don't have a per-CPU counter. The counter is
>> effective for a scope, e.g., a die or a socket. To address this, a
>> cpumask is exposed by the kernel driver to restrict to one CPU to stand
>> for a specific scope. In case the given CPU is removed,
>> the hotplug support has to be implemented for each such driver.
>>
>> The codes to support the cpumask and hotplug are very similar.
>> - Expose a cpumask into sysfs
>> - Pickup another CPU in the same scope if the given CPU is removed.
>> - Invoke the perf_pmu_migrate_context() to migrate to a new CPU.
>> - In event init, always set the CPU in the cpumask to event->cpu
>> - Usually, an event can be read from any CPU of the scope. (For now,
>> it is only supported by the pkg scope PMU, via
>> PERF_EV_CAP_READ_ACTIVE_PKG, e.g., cstate_pkg, rapl, etc)
>>
>> Similar duplicated codes are implemented for each such PMU driver. It
>> would be good to introduce a generic infrastructure to avoid such
>> duplication.
>>
>> The patch series introduce 5 popular scopes, core, die, cluster, pkg,
>> and the system-wide. The PMU drivers for cstate, iommu, idxd and rapl
>> are updated to apply the new infrastructure. The new infrastructure
>> can also be applied for other PMU drivers from different ARCHs as well.
>> But I don't have such platforms. It's not done in this patch series.
>> They can be added later separately.
>>
>> The uncore driver isn't updated either. Because a per-PMU cpumask is
>> required since commit c74443d92f68 ("perf/x86/uncore: Support per PMU
>> cpumask"). Since different types of PMU share the same hotplug codes,
>> more factor out works and verification are expected. The cleanup of the
>> uncore driver can be done later separately.
>>
>> Kan Liang (7):
>> perf: Generic hotplug support for a PMU with a scope
>> perf: Add PERF_EV_CAP_READ_SCOPE
>> perf/x86/intel/cstate: Clean up cpumask and hotplug
>> iommu/vt-d: Clean up cpumask and hotplug
>> dmaengine: idxd: Clean up cpumask and hotplug
>> perf/x86/rapl: Move the pmu allocation out of CPU hotplug
>> perf/x86/rapl: Clean up cpumask and hotplug
>>
>> arch/x86/events/intel/cstate.c | 140 +-------------------------
>> arch/x86/events/rapl.c | 119 ++++++----------------
>
> Looks like we have another RAPL driver in:
>
> drivers/powercap/intel_rapl_common.c
>
> that wants to be converted.
Right, but I need to talk with the power guys first. I have a vague
impression that some of the counters are not exactly PKG scope.
Thanks,
Kan
© 2016 - 2025 Red Hat, Inc.