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 ? If not, Samuel, could you resend and address s390 issue? I'm guessing wakeup sources just don't exist there.
