Hi,
this is the patch set I made to speed up the device
suspend/resume/shutdown process.
A new mechanism called Device Async Actions is introduced in this patch set.
The basic idea is that,
1. device declares to support certain kinds of device async action,
like suspend, resume, shutdown, etc.
2. a async domain is create for this device
3. the child device inherits the async domain
4. devices in the same domain suspend/resume/shutdown asynchronously with
the other devices.
Currently, in order to make sure that it won't bring any side effects,
I only convert the ACPI battery and i8042 to use this framework, which reduces
0.5s+ S3 time(suspend time plus resume time), from 7.0s to less than 6.5s.
and about 0.5s shutdown time in my test.
Any comments are welcome. :)
thanks,
rui
drivers/acpi/battery.c | 13 +++
drivers/base/Makefile | 3 +-
drivers/base/async_dev.c | 210 +++++++++++++++++++++++++++++++++++++++++++
drivers/base/core.c | 16 +++-
drivers/base/power/main.c | 10 ++-
drivers/input/serio/i8042.c | 10 ++-
include/linux/async.h | 3 +
include/linux/async_dev.h | 45 +++++++++
include/linux/device.h | 2 +
9 files changed, 306 insertions(+), 6 deletions(-)
Zhang Rui <[email protected]> writes:
>
> Currently, in order to make sure that it won't bring any side effects,
> I only convert the ACPI battery and i8042 to use this framework, which reduces
> 0.5s+ S3 time(suspend time plus resume time), from 7.0s to less than 6.5s.
10.5s+ was intended I guess?
-Andi
--
[email protected] -- Speaking for myself only.
Hi!
I notice you are still ccing my @suse.cz address. That one no longer
works :-(.
> this is the patch set I made to speed up the device
> suspend/resume/shutdown process.
>
> A new mechanism called Device Async Actions is introduced in this patch set.
> The basic idea is that,
> 1. device declares to support certain kinds of device async action,
> like suspend, resume, shutdown, etc.
> 2. a async domain is create for this device
> 3. the child device inherits the async domain
> 4. devices in the same domain suspend/resume/shutdown asynchronously with
> the other devices.
>
> Currently, in order to make sure that it won't bring any side effects,
> I only convert the ACPI battery and i8042 to use this framework, which reduces
> 0.5s+ S3 time(suspend time plus resume time)???, from 7.0s to less than 6.5s.
> and about 0.5s shutdown time in my test.
Hmm, 7seconds is still quite long. What hw is that?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, 2009-07-15 at 18:41 +0800, Andi Kleen wrote:
> Zhang Rui <[email protected]> writes:
> >
> > Currently, in order to make sure that it won't bring any side effects,
> > I only convert the ACPI battery and i8042 to use this framework, which reduces
> > 0.5s+ S3 time(suspend time plus resume time), from 7.0s to less than 6.5s.
>
> 10.5s+ was intended I guess?
>
what do you mean?
the kernel device suspend time is reduced from 3.2s to 2.8s after
applying this patch set in my test box.
And I get more optimistic numbers on another laptop, an Eeepc 901,
from about 2s to 1.6s. And the shutdown time is also reduced 0.4s.
thanks,
rui
On Thu, Jul 16, 2009 at 10:14:43AM +0800, Zhang Rui wrote:
> On Wed, 2009-07-15 at 18:41 +0800, Andi Kleen wrote:
> > Zhang Rui <[email protected]> writes:
> > >
> > > Currently, in order to make sure that it won't bring any side effects,
> > > I only convert the ACPI battery and i8042 to use this framework, which reduces
> > > 0.5s+ S3 time(suspend time plus resume time), from 7.0s to less than 6.5s.
> >
> > 10.5s+ was intended I guess?
> >
> what do you mean?
I am confused by you writing
"reduces <small number> from <much larger number> to <still larger number>"
So I assumed you dropped a decimal on <small number>
>
> the kernel device suspend time is reduced from 3.2s to 2.8s after
> applying this patch set in my test box.
> And I get more optimistic numbers on another laptop, an Eeepc 901,
> from about 2s to 1.6s. And the shutdown time is also reduced 0.4s.
I think I am still confused by your numbers.
How do the 0.5s and the 7.0s relate?
-Andi
--
[email protected] -- Speaking for myself only.
On Thu, 2009-07-16 at 16:07 +0800, Andi Kleen wrote:
> On Thu, Jul 16, 2009 at 10:14:43AM +0800, Zhang Rui wrote:
> > On Wed, 2009-07-15 at 18:41 +0800, Andi Kleen wrote:
> > > Zhang Rui <[email protected]> writes:
> > > >
> > > > Currently, in order to make sure that it won't bring any side effects,
> > > > I only convert the ACPI battery and i8042 to use this framework, which reduces
> > > > 0.5s+ S3 time(suspend time plus resume time), from 7.0s to less than 6.5s.
> > >
> > > 10.5s+ was intended I guess?
> > >
> > what do you mean?
>
> I am confused by you writing
>
> "reduces <small number> from <much larger number> to <still larger number>"
>
> So I assumed you dropped a decimal on <small number>
>
sorry for my poor English.
I mean the total S3 time (including kernel suspend and kernel resume)
reduces more than 0.5 second.
it takes 7.0s without this patch set and now it takes only 6.5s.
thanks,
rui
On Thu, 16 Jul 2009, Zhang Rui wrote:
> the kernel device suspend time is reduced from 3.2s to 2.8s after
> applying this patch set in my test box.
It will give even a bigger boot time saving on ThinkPads, where there is a
Synaptics (or ALPS if you are unlucky) touchpad with the trackpoint behind
it... it takes about 2s to init both devices here. That's two seconds of
boot time you can shove off if it is being initialized assyncronously :-)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh wrote:
> On Thu, 16 Jul 2009, Zhang Rui wrote:
>> the kernel device suspend time is reduced from 3.2s to 2.8s after
>> applying this patch set in my test box.
>
> It will give even a bigger boot time saving on ThinkPads, where there is a
> Synaptics (or ALPS if you are unlucky) touchpad with the trackpoint behind
> it... it takes about 2s to init both devices here. That's two seconds of
> boot time you can shove off if it is being initialized assyncronously :-)
>
that's a different problem that I don't think this will solve; as long
as you keep the boot of the kernel wait for all async actions, you're going
to hit that wait. In Moblin we have a (bad) patch to not do the wait,
at some point we need to figure how to get a mainline-able patch....
On Thu, Jul 16, 2009 at 3:45 PM, Arjan van de Ven<[email protected]> wrote:
> Henrique de Moraes Holschuh wrote:
>>
>> On Thu, 16 Jul 2009, Zhang Rui wrote:
>>>
>>> the kernel device suspend time is reduced from 3.2s to 2.8s after
>>> applying this patch set in my test box.
>>
>> It will give even a bigger boot time saving on ThinkPads, where there is a
>> Synaptics (or ALPS if you are unlucky) touchpad with the trackpoint behind
>> it... it takes about 2s to init both devices here. That's two seconds of
>> boot time you can shove off if it is being initialized assyncronously :-)
>>
>
> that's a different problem that I don't think this will solve; as long
> as you keep the boot of the kernel wait for all async actions, you're going
> to hit that wait. In Moblin we have a (bad) patch to not do the wait,
> at some point we need to figure how to get a mainline-able patch....
> --
Is it possible for you to post that patch (or point to a website hosting it)?
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, 2009-07-16 at 21:45 +0800, Arjan van de Ven wrote:
> Henrique de Moraes Holschuh wrote:
> > On Thu, 16 Jul 2009, Zhang Rui wrote:
> >> the kernel device suspend time is reduced from 3.2s to 2.8s after
> >> applying this patch set in my test box.
> >
> > It will give even a bigger boot time saving on ThinkPads, where there is a
> > Synaptics (or ALPS if you are unlucky) touchpad with the trackpoint behind
> > it... it takes about 2s to init both devices here. That's two seconds of
> > boot time you can shove off if it is being initialized assyncronously :-)
> >
>
> that's a different problem that I don't think this will solve;
right.
we are not able to get an async device group during initialization.
thanks,
rui
> as long
> as you keep the boot of the kernel wait for all async actions, you're going
> to hit that wait. In Moblin we have a (bad) patch to not do the wait,
> at some point we need to figure how to get a mainline-able patch....
On Wed, 2009-07-15 at 08:29 +0800, Pavel Machek wrote:
> Hi!
>
> I notice you are still ccing my @suse.cz address. That one no longer
> works :-(.
>
> > this is the patch set I made to speed up the device
> > suspend/resume/shutdown process.
> >
> > A new mechanism called Device Async Actions is introduced in this patch set.
> > The basic idea is that,
> > 1. device declares to support certain kinds of device async action,
> > like suspend, resume, shutdown, etc.
> > 2. a async domain is create for this device
> > 3. the child device inherits the async domain
> > 4. devices in the same domain suspend/resume/shutdown asynchronously with
> > the other devices.
> >
> > Currently, in order to make sure that it won't bring any side effects,
> > I only convert the ACPI battery and i8042 to use this framework, which reduces
> > 0.5s+ S3 time(suspend time plus resume time)???, from 7.0s to less than 6.5s.
> > and about 0.5s shutdown time in my test.
>
> Hmm, 7seconds is still quite long. What hw is that?
>
7 seconds including both kernel suspend and resume time.
it takes about 3.2s to suspend and 3.8 seconds to resume.
thanks,
rui