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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Mar 31, 2026 at 08:34:09AM -0700, Samuel Wu 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.

Describe "inefficient" please?

And if you really think that doing an open/read/close on a virtual
filesystem is inefficient, then I have the syscall for you!

I've been trying to get readfile() accepted every few years, looks like
I last tried in 2020:
	https://lore.kernel.org/r/20200704140250.423345-1-gregkh@linuxfoundation.org
but I keep the patchset up to date in my local tree all the time.

Would that help you out here instead?

> Adding kfuncs to lock/unlock wakeup sources allows BPF program to safely
> traverse the wakeup sources list. The head address of wakeup_sources can
> safely be resolved through BPF helper functions or variable attributes.

Who is going to be calling this?

> 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      |
> +-------+----+----------+----------+

150 sysfs calls in 44.9 ms feels very slow.  but really, what are you
expecting here, sysfs should NEVER be on a "fast path" that you care
about performance.  Why are you hammering on sysfs here?  What HAS to
have this type of performance?

In other words, what problem are you trying to solve that having access
to 150+ sysfs files all at once in a faster way is going to fix?

thanks,

greg k-h