On Fri, Mar 31, 2023 at 8:13 PM Limonciello, Mario <mario.limonciello@xxxxxxx> wrote: > > 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. Or whether or not it has been reached in any cycle so far? Or in the most recent 10 cycles? Or similar? Or how much time the system spent in HW sleep in general? > If it didn't they'll want to look at debug data from that cycle. > The aggregate will be noise. Not necessarily and the point is that you can relatively easily provide both values, the one from the most recent cycle and the grand total. > Do you think of another use case? Well, if the kernel can easily compute and expose the grand total value, why is it better to offload that to user space, possibly in different ways in different system configurations? What if somebody runs a minimum user space?
