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 <[email protected]> wrote: > > > > On Wed, May 13, 2026 at 2:51 AM Alexei Starovoitov > > <[email protected]> wrote: > > > > > > On Mon, May 11, 2026 at 1:44 PM Kumar Kartikeya Dwivedi > > > <[email protected]> wrote: > > > > > > > > On Mon, 11 May 2026 at 19:50, Samuel Wu <[email protected]> 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 <[email protected]> > > > > > > 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) <[email protected]> > > > > 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 <[email protected]>
