Re: [PATCH v5 1/4] PM: Add a sysfs file to represent time spent in hardware sleep state

[Limonciello, Mario]

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?