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

[Greg Kroah-Hartman]

On Wed, May 13, 2026 at 02:03:39PM -0700, Alexei Starovoitov wrote:
> 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.

I still feel it's really odd to be wanting to iterate over a zillion
sysfs files all at once, but sure, if this fixes the problem for this
user, might as well take it...

Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>