Hi, rafael On Sat, 2008-12-20 at 01:15 +0800, Rafael J. Wysocki wrote: > On Friday, 19 of December 2008, Zhang Rui wrote: > > Hi, all, > > > > The resume process can be split into 3 parts, BIOS resume time, kernel > > resume time and X/application resume time. > > And device resume takes most of the kernel resume time. > > this patch set introduces a new mechanism to resume device in parallel > > which can reduce the device resume time a lot. > > > > In this proposal, some devices can create its own workqueue for > > parallel resume. And for all the other devices that depends on this > > device, their resume methods are queued in the same workqueue. > > And we flush all the workqueues before resuming X/applications. > > > > As the devices vary from different platforms. it's hard to give an exact > > number of how much time it can reduce. > > Here are some of my test results: > > 1. eeepc901, kernel resume time can be reduced from about 2.1 seconds to > > 1.6 seconds. > > 2. a SantaRosa testbox, kernel resume time can be reduced from about > > 3.5s to 2s. > > > > please review this patch. Any comments are welcome. :) > > Well, given that our single-thread resume is not exactly correct, you mean that the current serial resume mechanism still doesn't work stable, right? > I think > it's _way_ to early to indroduce things like this. Right, it's not for upstream. But it looks good in theory, and it does works without any side effect in my case. So the patch was sent out here to see if there are some problems that are not covered by this patch, like the one Alan pointed out. :) thanks, rui -- 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
