Async suspend-resume patch w/ completions (was: Re: Async suspend-resume patch w/ rwsems)
in [Kernel]
|
Prev: [PATCH 3/4] ftrace - add fdd script
Next: drivers/media/video/uvc: Correct size given to memset
From: Rafael J. Wysocki on 19 Dec 2009 18:20 On Saturday 19 December 2009, Dmitry Torokhov wrote: > On Dec 19, 2009, at 1:33 PM, "Rafael J. Wysocki" <rjw(a)sisk.pl> 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? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 19 Dec 2009 18:30 On Dec 19, 2009, at 3:10 PM, "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > On Saturday 19 December 2009, Dmitry Torokhov wrote: >> On Dec 19, 2009, at 1:33 PM, "Rafael J. Wysocki" <rjw(a)sisk.pl> 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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 19 Dec 2009 18:40 On Sunday 20 December 2009, Dmitry Torokhov wrote: > On Dec 19, 2009, at 3:10 PM, "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > > > On Saturday 19 December 2009, Dmitry Torokhov wrote: > >> On Dec 19, 2009, at 1:33 PM, "Rafael J. Wysocki" <rjw(a)sisk.pl> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 19 Dec 2009 19:00 On Sunday 20 December 2009, Linus Torvalds wrote: > > On Sat, 19 Dec 2009, Linus Torvalds wrote: > > > > I suggest you try to treat the i8042 controller async, and see if it is > > problematic. If it isn't, don't do that then. > > I obviously meant: "If it _is_ problematic, don't do that then". "Is", not > "isn't". Sure, I understood that was a typo. :-) Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 19 Dec 2009 19:40
On Sunday 20 December 2009, Linus Torvalds wrote: > > On Sun, 20 Dec 2009, Rafael J. Wysocki wrote: > > > > > > Why would it be? > > > > The embedded controller may depend on it. > > Again, I say "why?" > > Anything can be true. That doesn't _make_ everything true. There's no real > reason why PnP/ACPI suspend/resume should really care. > > We can try it. Not for 2.6.33, but by the 34 merge window maybe we'll have > a patch-series that is ready to be tested, and that aggressively tries to > do the devices that matter asynchronously. Yes, I'd like to have such a patch series for 2.6.34. So far I've been able to confirm that doing serio+i8042, USB and ACPI battery asynchronously may give us significant time savings, especially during resume. > So instead of you trying to make up some idiotic cross-device worries, > just see if those worries have any actual background in reality. So far I > haven't actually heard anything but "in theory, anything is possible", > which is such a truism that it's not even worth voicing. > > That said, I still get the feeling that we'd be even better off simply > trying to avoid the whole keyboard reset entirely. Apparently we do it for > a few HP laptops. It's entirely possible that we'd be better off simply > not _doing_ the slow thing in the first place. That very well may be the case, but I'm not the right person to confirm or deny that. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |