Re: [PATCH v4 0/2] Support BPF traversal of wakeup sources

[Alexei Starovoitov]

On Wed, May 13, 2026 at 12:52 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> On Wed, May 13, 2026 at 2:51 AM Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> >
> > On Mon, May 11, 2026 at 1:44 PM Kumar Kartikeya Dwivedi
> > <memxor@xxxxxxxxx> wrote:
> > >
> > > On Mon, 11 May 2026 at 19:50, Samuel Wu <wusamuel@xxxxxxxxxx> wrote:
> > > >
> > > > This patchset adds requisite kfuncs for BPF programs to safely traverse
> > > > wakeup_sources, and puts a config flag around the sysfs interface.
> > > >
> > > > Currently, a traversal of wakeup sources require going through
> > > > /sys/class/wakeup/* or /d/wakeup_sources/*. The repeated syscalls to query
> > > > sysfs is inefficient, as there can be hundreds of wakeup_sources, with each
> > > > wakeup source also having multiple attributes. debugfs is unstable and
> > > > insecure.
> > > >
> > > > Adding kfuncs to lock/unlock wakeup sources allows BPF program to safely
> > > > traverse the wakeup sources list, and a kfunc to get head of wakeup
> > > > sources list is needed to start traversing the list.
> > > >
> > > > On a quiescent Pixel 6 traversing 150 wakeup_sources, I am seeing ~34x
> > > > speedup (sampled 75 times in table below). For a device under load, the
> > > > speedup is greater.
> > > > +-------+----+----------+----------+
> > > > |       | n  | AVG (ms) | STD (ms) |
> > > > +-------+----+----------+----------+
> > > > | sysfs | 75 | 44.9     | 12.6     |
> > > > +-------+----+----------+----------+
> > > > | BPF   | 75 | 1.3      | 0.7      |
> > > > +-------+----+----------+----------+
> > > >
> > > > The initial attempts for BPF traversal of wakeup_sources was with BPF
> > > > iterators [1]. However, BPF already allows for traversing of a simple list
> > > > with bpf_for(), and this current patchset has the added benefit of being
> > > > ~2-3x more performant than BPF iterators.
> > >
> > > This looks good to me, you can add for the set:
> > > Acked-by: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>
> >
> > Rafael,
> > how do you want to route it?
> >
> > If you ack it we can take it into bpf-next.
>
> I guess if someone really wants this, I have no particular reason to
> object, so please feel free to add
>
> Acked-by: Rafael J. Wysocki (Intel) <rafael@xxxxxxxxxx>
>
> to the first patch.
>
> > I'd think patch 1 shouldn't conflict with other 'wakeup' changes.
>
> Sure, there are none ATM anyway.

Thanks!

Greg,
are you ok with it too?
I hear your api concerns, but imo it's a nice improvement.
And bpf is not a stable interface despite some sceptics saying otherwise.
Just see how much sched-ext api surface has changed.

So if pm:wakeup folks need to tweak it later they're certainly
free to do it. Of course, it's better to keep things backward compact
and deprecate gradually. All options in developer's hands.