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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
