On 3/31/2023 13:07, Rafael J. Wysocki wrote:
On Fri, Mar 31, 2023 at 8:05 PM Limonciello, Mario
<mario.limonciello@xxxxxxx> wrote:
On 3/31/2023 13:01, Rafael J. Wysocki wrote:
On Thu, Mar 30, 2023 at 9:45 PM Mario Limonciello
<mario.limonciello@xxxxxxx> wrote:
Userspace can't easily discover how much of a sleep cycle was spent in a
hardware sleep state without using kernel tracing and vendor specific sysfs
or debugfs files.
To make this information more discoverable, introduce a new sysfs file
to represent the time spent in a sleep state.
This is only in the most recent suspend-resume cycle, isn't it?
Yes; that's correct.
Wouldn't it be useful to have another attribute printing the
accumulated total HW sleep time?
I had considered this; but I didn't think it was actually very useful
because userspace will get control at the end of every cycle and can
accumulate those numbers if desirable.
Unless "user space" in question is actually a human, that is.
This is what I envisioned:
* In traditional Linux some software like systemd could capture this and
log it.
It could subtract at the time the suspend started from the time it ended
and use that to calculate a percentage of time in hardware sleep state
and then put that percentage in the system journal.
* In ChromeOS something like powerd would be the only thing reading this
number and it could be adding it up during dark resume until the system
gets to a full resume.
* If a human is manually capturing these values they'll be most
interested in whether an individual cycle reached hardware sleep.
If it didn't they'll want to look at debug data from that cycle.
The aggregate will be noise.
Do you think of another use case?
