linux-kernel - Re: [RFT][PATCH v4 0/2] PM: sleep: Handle async suppliers like parents and async consumers like children

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: <f3667820-b911-4b31-ba41-e5b8d59e5065@amd.com>
Date: Sat, 28 Jun 2025 00:31:21 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Ulf Hansson <ulf.hansson@...aro.org>,
 "Rafael J. Wysocki" <rjw@...ysocki.net>, Linux PM
 <linux-pm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
 Chris Bainbridge <chris.bainbridge@...il.com>,
 Saravana Kannan <saravanak@...gle.com>, Sudeep Holla <sudeep.holla@....com>
Subject: Re: [RFT][PATCH v4 0/2] PM: sleep: Handle async suppliers like
 parents and async consumers like children

On 6/27/2025 12:31 PM, Rafael J. Wysocki wrote:
> On Fri, Jun 27, 2025 at 4:01 PM Mario Limonciello
> <mario.limonciello@....com> wrote:
>>
>> On 6/27/2025 5:40 AM, Rafael J. Wysocki wrote:
>>> On Fri, Jun 27, 2025 at 12:28 AM Mario Limonciello
>>> <mario.limonciello@....com> wrote:
>>>>
>>>> On 6/26/2025 4:46 AM, Ulf Hansson wrote:
>>>>> On Mon, 23 Jun 2025 at 14:55, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>>>>>>
>>>>>> Hi Everyone,
>>>>>>
>>>>>> These two patches complement the recently made PM core changes related to
>>>>>> the async suspend and resume of devices.  They should apply on top of
>>>>>> 6.16-rc3.
>>>>>>
>>>>>> They were sent along with the other changes mentioned above:
>>>>>>
>>>>>> https://lore.kernel.org/linux-pm/2229735.Mh6RI2rZIc@rjwysocki.net/
>>>>>> https://lore.kernel.org/linux-pm/2651185.Lt9SDvczpP@rjwysocki.net/
>>>>>>
>>>>>> (and this is v4 because they have been rebased in the meantime), but they don't
>>>>>> make any difference on my test-bed x86 systems, so I'd appreciate a confirmation
>>>>>> that they are actually needed on ARM (or another architecture using DT).
>>>>>>
>>>>>> Thanks!
>>>>>
>>>>> Hi Rafael,
>>>>>
>>>>> I haven't yet got the time to test these, but the code looks good to
>>>>> me, so feel free to add for the series:
>>>>>
>>>>> Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>
>>>>>
>>>>> Kind regards
>>>>> Uffe
>>>>
>>>> I passed this series to some internal guys to test on a wide variety of
>>>> AMD x86 hardware.  The initial testing looks good.
>>>> Will keep you apprised if anything pops up.
>>>
>>> Thanks!
>>>
>>> It would also help if you could check whether or not there is any
>>> measurable performance (that is, system suspend and resume time)
>>> difference between "before" and "after".
>>
>> Sure thing.
>>
>> Just to make sure we have an aligned measurement methodology:
>>
>> I asked them to do this both with and without the patches.
>>
>> * set /sys/power/pm_debug_messages before running and then capture all
>> the timing prints.
>> * add up all suspend events and get a total
>> * add up all resume events and get a total
>> * repeat 5 times
>> * calculate averages for the 5 runs
> 
> Sounds good!

This is across two different systems.

The first one didn't have a very large difference in average (20ms)

KRK No patch
Suspend 235.6862
Resume 2220.3976

KRK patch
Suspend 233.3544
Resume 2202.199

The second one had about a 15% drop in average suspend time; but I think 
I suspect this isn't a big enough data sample.  I say that because both 
sides had one cycle take longer than the rest on avearge.

STX nopatch
Suspend 774.39638
Resume 1893.5252

STX patch
Suspend 651.9756
Resume 1895.725

If I exclude that long cycle on both (so average of 4) the drop is 10%

STX No patch
Suspend 319.353725
Resume 2256.0025

STX patch
Suspend	292.482
Resume 2257.27


I'm personally thinking 5 cycles isn't enough for showing "real" gains 
are there.
Probably need a much larger sample size to get statistically relevant 
numbers.