On Sunday 20 December 2009, Dmitry Torokhov wrote: > 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. That I already knew. :-) > I8042 itself may have indirect dependency on a couple of PNP devices. I was really asking about these. > I hope this answers your question... Yes, thanks. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
