linux-kernel - Re: [PATCH v3 0/5] PM: sleep: Improvements of async suspend and resume of devices

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: <CAGETcx8VmzU9xy39=_QAQ0pf5fZY=EbGOKrdy0_wLEW1pQ2oKw@mail.gmail.com>
Date: Fri, 14 Mar 2025 14:06:15 -0700
From: Saravana Kannan <saravanak@...gle.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Linux PM <linux-pm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Alan Stern <stern@...land.harvard.edu>, Ulf Hansson <ulf.hansson@...aro.org>, 
	Johan Hovold <johan@...nel.org>, Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>, 
	Jon Hunter <jonathanh@...dia.com>
Subject: Re: [PATCH v3 0/5] PM: sleep: Improvements of async suspend and
 resume of devices

On Fri, Mar 14, 2025 at 6:24 AM Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>
> Hi Everyone,
>
> This is a new iteration of the async suspend/resume improvements work:
>
> https://lore.kernel.org/linux-pm/1915694.tdWV9SEqCh@rjwysocki.net/
>
> which includes some rework and fixes of the patches in the series linked
> above.  The most significant differences are splitting the second patch
> into two patches and adding a change to treat consumers like children
> during resume.
>
> This new iteration is based on linux-pm.git/linux-next and on the recent
> fix related to direct-complete:
>
> https://lore.kernel.org/linux-pm/12627587.O9o76ZdvQC@rjwysocki.net/
>
> The overall idea is still to start async processing for devices that have
> at least some dependencies met, but not necessarily all of them, to avoid
> overhead related to queuing too many async work items that will have to
> wait for the processing of other devices before they can make progress.
>
> Patch [1/5] does this in all resume phases, but it just takes children
> into account (that is, async processing is started upfront for devices
> without parents and then, after resuming each device, it is started for
> the device's children).
>
> Patches [2/5] does this in the suspend phase of system suspend and only
> takes parents into account (that is, async processing is started upfront
> for devices without any children and then, after suspending each device,
> it is started for the device's parent).
>
> Patch [3/5] extends it to the "late" and "noirq" suspend phases.
>
> Patch [4/5] adds changes to treat suppliers like parents during suspend.
> That is, async processing is started upfront for devices without any
> children or consumers and then, after suspending each device, it is
> started for the device's parent and suppliers.
>
> Patch [5/5] adds changes to treat consumers like children during resume.
> That is, async processing is started upfront for devices without a parent
> or any suppliers and then, after resuming each device, it is started for
> the device's children and consumers.
>
> Preliminary test results from one sample system are below.
>
> "Baseline" is the linux-pm.git/testing branch, "Parent/child"
> is that branch with patches [1-3/5] applied and "Device links"
> is that branch with patches [1-5/5] applied.
>
> "s/r" means "regular" suspend/resume, noRPM is "late" suspend
> and "early" resume, and noIRQ means the "noirq" phases of
> suspend and resume, respectively.  The numbers are suspend
> and resume times for each phase, in milliseconds.
>
>          Baseline       Parent/child    Device links
>
>        Suspend Resume  Suspend Resume  Suspend Resume
>
> s/r    427     449     298     450     294     442
> noRPM  13      1       13      1       13      1
> noIRQ  31      25      28      24      28      26
>
> s/r    408     442     298     443     301     447
> noRPM  13      1       13      1       13      1
> noIRQ  32      25      30      25      28      25
>
> s/r    408     444     310     450     298     439
> noRPM  13      1       13      1       13      1
> noIRQ  31      24      31      26      31      24
>
> It clearly shows an improvement in the suspend path after
> applying patches [1-3/5], easily attributable to patch [2/5],
> and clear difference after updating the async processing of
> suppliers and consumers.
>
> Note that there are systems where resume times are shorter after
> patches [1-3/5] too, but more testing is necessary.
>
> I do realize that this code can be optimized further, but it is not
> particularly clear to me that any further optimizations would make
> a significant difference and the changes in this series are deep
> enough to do in one go.

Thanks for adding patches 4 and 5!

Let me try to test them early next week and compare your patches 1-3,
1-5 and my series (which does additional checks to make sure
suppliers/consumers are done). I do about 100 suspend/resume runs for
each kernel, so please bear with me while I get it.

Thanks,
Saravana