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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8a04da89-1c98-8b29-bf96-1e8d0ed47e58@amd.com>
Date:   Fri, 31 Mar 2023 13:13:43 -0500
From:   "Limonciello, Mario" <mario.limonciello@....com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Sven van Ashbrook <svenva@...omium.org>,
        John Stultz <jstultz@...gle.com>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        Raul Rangel <rrangel@...omium.org>,
        David E Box <david.e.box@...el.com>,
        Rajat Jain <rajatja@...gle.com>,
        S-k Shyam-sundar <Shyam-sundar.S-k@....com>,
        Hans de Goede <hdegoede@...hat.com>,
        linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        linux-pm@...r.kernel.org
Subject: Re: [PATCH v5 1/4] PM: Add a sysfs file to represent time spent in
 hardware sleep state

On 3/31/2023 13:07, Rafael J. Wysocki wrote:
> On Fri, Mar 31, 2023 at 8:05 PM Limonciello, Mario
> <mario.limonciello@....com> wrote:
>>
>> On 3/31/2023 13:01, Rafael J. Wysocki wrote:
>>> On Thu, Mar 30, 2023 at 9:45 PM Mario Limonciello
>>> <mario.limonciello@....com> 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?