[RFC PATCH 0/3] pm: device parallel resume mechanism

[RFC PATCH 0/3] pm: device parallel resume mechanism

[Zhang Rui]

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. :)

thanks,
rui

Re: [RFC PATCH 0/3] pm: device parallel resume mechanism

[Rafael J. Wysocki]

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, I think
it's _way_ to early to indroduce things like this.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/3] pm: device parallel resume mechanism

[Zhang Rui]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/3] pm: device parallel resume mechanism

[Rafael J. Wysocki]

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