Re: Async suspend-resume patch w/ completions (was: Re: Asyncsuspend-resume patch w/ rwsems)

From: Linus Torvalds
Date: Wed Dec 16 2009 - 10:48:47 EST




On Wed, 16 Dec 2009, Rafael J. Wysocki wrote:
>
> The summarized data are below (the "big" numbers are averages and the +/-
> numbers are standard deviations, all in milliseconds):
>
> HP nx6325 MSI Wind U100
>
> sync suspend 1482 (+/- 40) 1180 (+/- 24)
> sync resume 2955 (+/- 2) 3597 (+/- 25)
>
> async suspend 1553 (+/- 49) 1177 (+/- 32)
> async resume 2692 (+/- 326) 3556 (+/- 33)
>
> async+one-liner suspend 1600 (+/- 39) 1212 (+/- 41)
> async+one-liner resume 2692 (+/- 324) 3579 (+/- 24)
>
> async+extra suspend 1496 (+/- 37) 1217 (+/- 38)
> async+extra resume 1859 (+/- 114) 1923 (+/- 35)
>
> So, in my opinion, with the above set of "async" devices, it doesn't
> make sense to do async suspend at all, because the sync suspend is actually
> the fastest on both machines.

Hmm. I certainly agree - your numbers do not seem to support any async at
all.

However, I do note that for the "extra patch" makes a big difference at
resume time. That implies that the resume serializes on some slow device
that wasn't marked async - and starting the async ones early avoids that.

But without the per-device timings, it's hard to even guess what device
that was.

But even that doesn't really help the suspend cases, only resume.

Do you have any sample timing output with devices listed?

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/