Re: [PATCH 2/4] perf/core: Add PERF_PMU_SCOPE_DEVICE

[Okanovic, Haris]

On Wed, 2026-10-14 at 15:26 +0100, Robin Murphy wrote:
> On 2026-10-14 11:27 am, Peter Zijlstra wrote:
> > On Tue, Oct 13, 2026 at 01:56:01PM -0500, Haris Okanovic wrote:
> >> The initial CPU assignment can race with migration, leaving a stranded
> >> event. A sequence counter is added to close this gap without additional
> >> locks. A count in struct pmu increments on each migration and is copied
> >> to struct perf_event on init. The copied count is checked again before
> >> the event is installed, under the same context mutex, which causes
> >> perf_event_open() and perf_event_create_kernel_counter() to return -EBUSY
> >> during migration periods.
> >
> > I'm not entirely sure on this. How is this race different from changing
> > CPU on hotplug?
>
> Not much, other than that hotplug is at least already serialised against
> perf_event_open on the perf core side via perf_online_mask. This is also
> where I was heading with my generic hotplug proposal[1] - once perf core
> can be in charge of that, it should then be viable to also migrate PMUs
> for reasons other than hotplug, and it would all look the same to the
> drivers.

Agreed, it's not a new issue. It does get worse once migration can happen
outside of hotplug, which is the next patch of this series: stranded events
don't get torn down since the source CPU stays online. I'm happy to split
the sequence counter into its own patch if that reads better.

> (Yes, as-is my patch still preserves the status quo of drivers picking
> their own target CPU to keep things simple, but that was one of the
> points I was hoping to generate some discussion on...)

Having perf core choose the target lets us spread load across CPUs, which
was a good point from an earlier thread [2]. This change does that with
a simple cpumask_any_distribute().

[1] https://lore.kernel.org/linux-arm-kernel/cover.1784911757.git.robin.murphy@xxxxxxx/
[2] https://lore.kernel.org/linux-arm-kernel/2d70be7b-12c0-46e0-b308-744a3159388a@xxxxxxx/

-- 
Haris Okanovic
AWS Graviton