From: Joshua Crofts <crofts@kernel.org>
To: Samuel Wu <wusamuel@google.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>, Pavel Machek <pavel@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Danilo Krummrich <dakr@kernel.org>,
Johan Hovold <johan@kernel.org>,
linux-pm@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org,
Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: [PATCH 0/3] PM: runtime: add new runtime metrics and summary
Date: Thu, 12 Nov 2026 09:42:54 +0100 [thread overview]
Message-ID: <20261112094254.00003d3d@kernel.org> (raw)
In-Reply-To: <CAG2KctqMYi+a-NZm7bAHTSc5Ch8=RAaEhY6CAZkvCnGW2VOeEA@mail.gmail.com>
On Wed, 11 Nov 2026 08:56:30 -0800
Samuel Wu <wusamuel@google.com> wrote:
...
> > The main things this is useful for are detecting power "thrashing" and
> > tuning autosuspend delays. Currently, sysfs only shows the total time
> > a device spent in active and suspended mode; from an energy standpoint,
> > a continuous 50 second suspension is different from a device cycling
> > 1000 times for 50ms each (these transitions can be pretty power-hungry).
> > This could help userspace utilities like PowerTOP to more effectively
> > determine what is causing an increased power consumption.
> >
> > From the kernel dev standpoint - this is genuinely useful when testing
> > runtime PM functions in new drivers (for example in the IIO subsystem we
> > deal with a lot of runtime PM stuff).
>
> Makes sense, there is value in this info.
>
> > > And is there a reason the stats need to be surfaced in both sysfs and debugfs?
> >
> > sysfs definitely, as you should definitely be able to access this info
> > per-device (and this is the way userspace tools would get this info).
>
> Is there already a userspace user of these sysfs nodes?
No, there isn't.
> Adding these five sysfs nodes would easily create 10k+ new sysfs nodes
> (a typical Android device can easily have 2k+ devices). Most userspace
> apps would iterate through every possible node, meaning this would be
> an inconsistent snapshot across the 10k+ syscalls, in addition to
> being inefficient.
>
> These sysfs nodes would have a boot time impact, a non-negligible
> memory impact, and constitute a permanent ABI.
Fair enough, I didn't account for this. 2k+ devices is a lot!
> > The debugfs summary is however pretty elegant IMO and useful. I'm sure a lot
> > of people investigating odd device behaviour would like this (plus there
> > are overviews like this in the kernel already - clk_summary for example).
>
> The debugfs addition makes more sense IMO. It filters with
> pm_runtime_enabled() instead of presenting every device, and the
> spinlock at least keeps the view of each device consistent. It's also
> more flexible without the ABI guarantee.
Okay, I've no problem with dropping the sysfs patch. The debugfs summary is
machine-readable for any userspace tools to parse.
--
Kind regards,
Joshua Crofts
prev parent reply other threads:[~2026-11-12 8:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 10:43 [PATCH 0/3] PM: runtime: add new runtime metrics and summary Joshua Crofts
2026-11-10 10:43 ` [PATCH 1/3] PM: runtime: add additional suspend/resume metrics Joshua Crofts
2026-11-10 10:43 ` [PATCH 2/3] PM: add sysfs attributes for " Joshua Crofts
2026-11-10 17:29 ` Greg Kroah-Hartman
2026-11-10 18:50 ` Joshua Crofts
2026-11-10 18:54 ` Greg Kroah-Hartman
2026-11-10 18:58 ` Greg Kroah-Hartman
2026-11-10 19:02 ` Joshua Crofts
2026-11-10 21:16 ` Greg Kroah-Hartman
2026-11-10 10:43 ` [PATCH 3/3] PM: runtime: add debugfs entry for pm_runtime_summary Joshua Crofts
2026-11-11 3:38 ` [PATCH 0/3] PM: runtime: add new runtime metrics and summary Samuel Wu
2026-11-11 9:11 ` Joshua Crofts
2026-11-11 16:56 ` Samuel Wu
2026-11-12 8:42 ` Joshua Crofts [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261112094254.00003d3d@kernel.org \
--to=crofts@kernel.org \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=pavel@kernel.org \
--cc=rafael@kernel.org \
--cc=wusamuel@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.