On Friday 25 December 2009, Nigel Cunningham wrote: > Rafael J. Wysocki wrote: > > On Thursday 24 December 2009, Nigel Cunningham wrote: > >> Hi. > > > > Hi, > > > >> I built the async branch of your tree and tested it, also running > >> 2.6.33-rc1 + TuxOnIce for comparison. Dmesg for both are attached. Is > >> there anything I can/should be doing for you on top of this? > > > > No, thanks a lot. > > > >> I'll try Dmitry's patch on top of this a little later - other things to do first. > > > > No need for that, the patchset contains an equivalent of the Dmitry's patch. > > > >> I noticed that you were doing standard deviations in your stats - how > >> many runs were you basing them on? > > > > I usually run 10 iterations of suspend-resume for each configuration. > > The raw data are at http://www.sisk.pl/kernel/data/async-suspend-updated.pdf > > if you're interested. > > > >> Not sure that I can be bothered to do too many - too much else to do! > > > > Sure, thanks a lot anyway. Your data confirn that there's a measurable gain > > from suspending and resuming devices asynchronously. > > It did? I thought it showed no difference at all! Yes, it did. Please compare these lines: (from the "sync" dmesg): [ 31.640676] PM: freeze of devices complete after 709.277 msecs [ 37.087548] PM: restore of devices complete after 4973.508 msecs (from the "async" dmesg): [ 25.600067] PM: freeze of devices complete after 620.429 msecs [ 29.195366] PM: restore of devices complete after 3057.982 msecs So clearly, there's a difference. :-) Of course, in terms of total hibernate/restore time this is only a little improvement, but if that was suspend to RAM and resume, the reduction of the device resume time by almost 2 s would be a big deal. > I'll see if I can find the time to do the other computers, then. I'd appreciate that very much. > We're going away for a couple of weeks on Monday, though, so I'm not sure > that I'll get the time beforehand. OK 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
