On Wednesday 16 December 2009, Linus Torvalds wrote: > > 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? I'm going to generate one shortly. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
