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

[Mario Limonciello]

On 6/27/2025 12:31 PM, Rafael J. Wysocki wrote:
> On Fri, Jun 27, 2025 at 4:01 PM Mario Limonciello
> <mario.limonciello@xxxxxxx> 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@xxxxxxx> wrote:
> > > > On 6/26/2025 4:46 AM, Ulf Hansson wrote:
> > > > > On Mon, 23 Jun 2025 at 14:55, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx/
> > > > > > https://lore.kernel.org/linux-pm/2651185.Lt9SDvczpP@xxxxxxxxxxxxx/
> > > > > >
> > > > > > (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@xxxxxxxxxx>
> > > > >
> > > > > 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.