[PATCH v1 0/2] *** Support BPF traversal of wakeup sources ***

Samuel Wu posted 2 patches 2 weeks ago
drivers/base/power/Makefile |  3 +-
drivers/base/power/power.h  | 14 +++++++++
drivers/base/power/wakeup.c | 63 +++++++++++++++++++++++++++++++++++--
kernel/power/Kconfig        | 13 ++++++++
4 files changed, 90 insertions(+), 3 deletions(-)
[PATCH v1 0/2] *** Support BPF traversal of wakeup sources ***
Posted by Samuel Wu 2 weeks ago
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. The head address of wakeup_sources can
safely be resolved through BPF helper functions or variable attributes.

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

On the memory side, between kernfs, dentry, and kmalloc, each wakeup source
removed from sysfs saves at least 10kB.

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.

[1]: https://lore.kernel.org/all/20260225210820.177674-1-wusamuel@google.com/

Samuel Wu (2):
  PM: wakeup: Add kfuncs to lock/unlock wakeup_sources
  PM: Add config flag to gate sysfs wakeup_sources

 drivers/base/power/Makefile |  3 +-
 drivers/base/power/power.h  | 14 +++++++++
 drivers/base/power/wakeup.c | 63 +++++++++++++++++++++++++++++++++++--
 kernel/power/Kconfig        | 13 ++++++++
 4 files changed, 90 insertions(+), 3 deletions(-)

-- 
2.53.0.959.g497ff81fa9-goog
Re: [PATCH v1 0/2] *** Support BPF traversal of wakeup sources ***
Posted by Kumar Kartikeya Dwivedi 1 week, 6 days ago
On Fri, 20 Mar 2026 at 17:01, Samuel Wu <wusamuel@google.com> 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. The head address of wakeup_sources can
> safely be resolved through BPF helper functions or variable attributes.
>
> 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      |
> +-------+----+----------+----------+
>
> On the memory side, between kernfs, dentry, and kmalloc, each wakeup source
> removed from sysfs saves at least 10kB.
>
> 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.

See, it ended up being faster ;-).

That said, I didn't understand why you dropped the test. We still need
unit tests that ensure the verifier causes the bpf_ws_lock to be
released before exit, and an example program (like the one you
benchmarked with) to demonstrate usage. Both are mandatory. See
various *_fail.c files in progs/ and RUN_TESTS() macro for running
negative tests easily. I doubt we will have any wakeup_sources in the
CI environment, but the example has value nonetheless.

pw-bot: cr

>
> [1]: https://lore.kernel.org/all/20260225210820.177674-1-wusamuel@google.com/
>
> Samuel Wu (2):
>   PM: wakeup: Add kfuncs to lock/unlock wakeup_sources
>   PM: Add config flag to gate sysfs wakeup_sources
>
>  drivers/base/power/Makefile |  3 +-
>  drivers/base/power/power.h  | 14 +++++++++
>  drivers/base/power/wakeup.c | 63 +++++++++++++++++++++++++++++++++++--
>  kernel/power/Kconfig        | 13 ++++++++
>  4 files changed, 90 insertions(+), 3 deletions(-)
>
> --
> 2.53.0.959.g497ff81fa9-goog
>
Re: [PATCH v1 0/2] *** Support BPF traversal of wakeup sources ***
Posted by Samuel Wu 1 week, 4 days ago
On Sat, Mar 21, 2026 at 10:52 AM Kumar Kartikeya Dwivedi
<memxor@gmail.com> wrote:
>

[ ... ]

> >
> > 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.
>
> See, it ended up being faster ;-).

Yup, thanks for the suggestion!

>
> That said, I didn't understand why you dropped the test. We still need
> unit tests that ensure the verifier causes the bpf_ws_lock to be
> released before exit, and an example program (like the one you
> benchmarked with) to demonstrate usage. Both are mandatory. See
> various *_fail.c files in progs/ and RUN_TESTS() macro for running
> negative tests easily. I doubt we will have any wakeup_sources in the
> CI environment, but the example has value nonetheless.
>
> pw-bot: cr
>

Sounds good, in v2 I can add a test for the lock/unlock kfunc. And
thanks for the thorough feedback, let me take a look at the *_fail.c
files and test macros.