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

[Mario Limonciello <mario.limonciello@amd.com>]

On 6/27/2025 12:31 PM, Rafael J. Wysocki wrote:
> On Fri, Jun 27, 2025 at 4:01 PM Mario Limonciello
> <mario.limonciello@amd.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@amd.com> wrote:
>>>>
>>>> On 6/26/2025 4:46 AM, Ulf Hansson wrote:
>>>>> On Mon, 23 Jun 2025 at 14:55, Rafael J. Wysocki <rjw@rjwysocki.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@linaro.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.