On Dec 19, 2009, at 3:10 PM, "Rafael J. Wysocki" <rjw@xxxxxxx> wrote:
On Saturday 19 December 2009, Dmitry Torokhov wrote:
On Dec 19, 2009, at 1:33 PM, "Rafael J. Wysocki" <rjw@xxxxxxx> wrote:
On Saturday 19 December 2009, Dmitry Torokhov wrote:
On Fri, Dec 18, 2009 at 11:43:29PM +0100, Rafael J. Wysocki wrote:
On Wednesday 16 December 2009, Dmitry Torokhov wrote:
On Wed, Dec 16, 2009 at 03:11:05AM +0100, Rafael J. Wysocki
wrote:
On Tuesday 15 December 2009, Linus Torvalds wrote:
On Tue, 15 Dec 2009, Rafael J. Wysocki wrote:
Give a real example that matters.
I'll try. Let -> denote child-parent relationships and assume
dpm_list looks
like this:
No.
I mean something real - something like
- if you run on a non-PC with two USB buses behind non-PCI
controllers.
- device xyz.
If this applies to _resume_ only, then I agree, but the
Arjan's data clearly
show that serio devices take much more time to suspend than
USB.
I mean in general - something where you actually have hard data
that some
device really needs anythign more than my one-liner, and really
_needs_
some complex infrastructure.
Not "let's imagine a case like xyz".
As I said I would, I made some measurements.
I measured the total time of suspending and resuming devices as
shown by the
code added by this patch:
http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-2.6.git;a=commitdiff_plain;h=c1b8fc0a8bff7707c10f31f3d26bfa88e18ccd94;hp=087dbf5f079f1b55cbd3964c9ce71268473d5b67
on two boxes, HP nx6325 and MSI Wind U100 (hardware-wise they
are quite
different and the HP was running 64-bit kernel and user space).
I took four cases into consideration:
(1) synchronous suspend and resume (/sys/power/pm_async = 0)
(2) asynchronous suspend and resume as introduced by the async
branch at:
http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-2.6.git;a=shortlog;h=refs/heads/async
(3) asynchronous suspend and resume like in (2), but with your
one-liner setting
the power.async_suspend flag for PCI bridges on top
(4) asynchronous suspend and resume like in (2), but with an
extra patch that
is appended on top
For those tests I set power.async_suspend for all USB devices,
all serio input
devices, the ACPI battery and the USB PCI controllers (to see
the impact of the
one-liner, if any).
I carried out 5 consecutive suspend-resume cycles (started from
under X) on
each box in each case, and the raw data are here (all times in
milliseconds):
http://www.sisk.pl/kernel/data/async-suspend.pdf
The summarized data are below (the "big" numbers are averages
and the +/-
numbers are standard deviations, all in milliseconds):
HP nx6325 MSI Wind U100
sync suspend 1482 (+/- 40) 1180 (+/- 24)
sync resume 2955 (+/- 2) 3597 (+/- 25)
async suspend 1553 (+/- 49) 1177 (+/- 32)
async resume 2692 (+/- 326) 3556 (+/- 33)
async+one-liner suspend 1600 (+/- 39) 1212 (+/- 41)
async+one-liner resume 2692 (+/- 324) 3579 (+/- 24)
async+extra suspend 1496 (+/- 37) 1217 (+/- 38)
async+extra resume 1859 (+/- 114) 1923 (+/- 35)
So, in my opinion, with the above set of "async" devices, it
doesn't
make sense to do async suspend at all, because the sync suspend
is actually
the fastest on both machines.
I think the async suspend is not asynchronous enough then - what
kind of
time do you get if you simply comment out call to psmouse_reset()
in
drivers/input/mouse/psmouse-base.c:psmouse_cleanup()? (Just for
testing
purposes only, I don't think we want to do that by default.)
The problem apparently is that the i8042 suspend/resume is
synchronous.
Do you think it's safe to mark it as asynchronous?
Umm.. there lie dragons. There is an implicit relationship between
i8042
and PNP/ACPI devices representing keyboard and mouse ports, and I
am not
sure how happy i8042 (and most importantly the BIOS) will be if
they get
shut down before i8042. Also there is EC which is in theory
independent
but in practice not so much.
I see.
Is this possible to identify ACPI devices that should wait for the
i8042
suspend and that should be waited for by it on resume?
We could try to add some dependencies while discovering PNP to get
KBC
addresses in i8042 but we need tomake sure we do it even in presence
of i8042.nopnp.
Well, I guess this is the example of the off-tree dependencies that
actually
matter Linus wanted. :-)
I guess there are quite a few devices that can depend on the i8042 in
principle, is this correct?
The devices that depend on i8042 are serio ports that are it's
children. I8042 itself may have indirect dependency on a couple of PNP
devices.
I hope this answers your question...
--
Dmitry
--
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
