On Sun, Apr 12, 2026 at 9:48 PM Greg Kroah-Hartman <[email protected]> wrote: > > On Sun, Apr 12, 2026 at 03:48:58PM -0700, Alexei Starovoitov wrote: > > On Fri, Apr 3, 2026 at 9:28 AM Samuel Wu <[email protected]> wrote: > > > > > > On Fri, Apr 3, 2026 at 3:04 AM Greg Kroah-Hartman > > > <[email protected]> wrote: > > > > > > > > On Thu, Apr 02, 2026 at 12:37:12PM -0700, Samuel Wu wrote: > > > > > On Wed, Apr 1, 2026 at 9:06 PM Greg Kroah-Hartman > > > > > <[email protected]> wrote: > > > > > > > > > > > > On Wed, Apr 01, 2026 at 12:07:12PM -0700, Samuel Wu wrote: > > > > > > > On Wed, Apr 1, 2026 at 2:15 AM Greg Kroah-Hartman > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > On Tue, Mar 31, 2026 at 08:34:09AM -0700, Samuel Wu wrote: > > > > > > [ ... ] > > > > > > > > The data is fundamental for debugging and improving power at scale. > > > > > The original discussion and patch [1] provide more context of the > > > > > intent. To summarize the history, debugfs was unstable and insecure, > > > > > leading to the current sysfs implementation. However, sysfs has the > > > > > constraint of one attribute per node, requiring 10 sysfs accesses per > > > > > wakeup source. > > > > > > > > Ok, as the sysfs api doesn't work your use case anymore, why do we need > > > > to keep it around at all? > > > > > > > > > That said, I completely agree that reading 1500+ sysfs files at once > > > > > is unreasonable. Perhaps the sysfs approach was manageable at the time > > > > > of [1], but moving forward we need a more scalable solution. This is > > > > > the main motivator and makes BPF the sane approach, as it improves > > > > > traversal in nearly every aspect (e.g. cycles, memory, simplicity, > > > > > scalability). > > > > > > > > I'm all for making this more scalable and work for your systems now, but > > > > consider if you could drop the sysfs api entirely, would you want this > > > > to be a different type of api entirely instead of having to plug through > > > > these using ebpf? > > > > > > Almost all use cases want all this data at once, so AFAICT BPF offers > > > the best performance for that. But of course, open to discussion if > > > there is an alternative API that matches BPF's performance for this > > > use case. > > > > > > I'm not opposed to dropping the sysfs approach, and I attempted to do > > > so in the v1 patch [1]. I'm not sure who else currently uses those > > > sysfs nodes, but a config flag should remove friction and could be a > > > stepping stone toward deprecation/removal. > > > > > > [1]: > > > https://lore.kernel.org/all/[email protected]/ > > > > The patches make sense to me. > > > > Patch 2 adds a bpf selftest and corresponding: > > +CONFIG_DIBS_LO=y > > +CONFIG_PM_WAKELOCKS=y > > > > and almost green in BPF CI. > > > > Except s390 that fails with: > > > > Error: #682/1 wakeup_source/iterate_and_verify_times > > Error: #682/1 wakeup_source/iterate_and_verify_times > > libbpf: extern (func ksym) 'bpf_wakeup_sources_get_head': not found in > > kernel or module BTFs > > libbpf: failed to load BPF skeleton 'test_wakeup_source': -EINVAL > > test_wakeup_source:FAIL:skel_open_and_load unexpected error: -22 > > > > We can still land it into bpf-next for this merge window. > > > > Greg, > > any objection ? > > Yes, it is too late for 7.1-rc1, sorry, there will have not been any > time in linux-next to add it. Let's revisit it after -rc1 is out, and > again, I feel that "walk all sysfs devices in bpf" is not the correct > solution for a system-wide snapshot interface you want to have, > especially as the one you previously added you feel is now obsolete.
Sounds good, when the merge window closes, I'll send out v4 with the s390 errors and remaining comments fixed. Regarding surfacing a system-wide snapshot of wakeup sources to userspace, can you elaborate on the solution you're envisioning? My understanding is that "walk all sysfs devices in bpf" is a canonical BPF use case, especially in this scenario, where we see improvements in every core metric.
