On Monday, 22 of December 2008, Zhang Rui wrote: > Hi, rafael Hi, > 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? Not exactly. I mean it isn't _done_ right and not working correctly is just a consequence of this. For this reason, we should first fix the current code and _then_ build add new features like this, not the other way around. > > > 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. :) OK Thanks, 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
