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 11:00 On Friday 18 December 2009, Rafael J. Wysocki wrote: > On Thursday 17 December 2009, Rafael J. Wysocki wrote: > ... > > Tomorrow I'll try to mark as many devices as reasonably possible as async > > and see how the total suspend-resume times change. > > I didn't manage to do that, but I was able to mark sd and i8042 as async and > see the impact of this. > > The raw data are in the usual place: > > http://www.sisk.pl/kernel/data/async-suspend-resume.pdf > > and the individual device timings and logs are in: > > http://www.sisk.pl/kernel/data/nx6325/ > http://www.sisk.pl/kernel/data/wind/ > > This is the summary (previous results are inculded for easier reference): > > 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) > > with "async" i8042 and sd: > > async suspend 1319 (+/- 51) 1045 (+/- 41) > async resume 2929 (+/- 3) 3546 (+/- 27) > > async+extra suspend 1327 (+/- 36) (didn't work) > async+extra resume 1742 (+/- 164) 1896 (+/- 28) > > (the summary is also available at: http://www.sisk.pl/kernel/data/results.txt). > > So, it actually makes the case for async suspend! Although it's not very > strong, with these two additional devices marked as "async" we get noticeable > suspend time improvement. > > Still, the "extra" patch doesn't help on suspend at all and on the Wind the > suspend part of it didn't even work (I'm yet to figure out which of the two > devices crashed the suspend). Small update. I've just verified that sd was the failing device, although I'm not sure about the reason. Apart from this, I ran some tests on the Wind with i8042 marked as "async" and sd marked as "sync". In that case all of the tests succeeded and I got the following numbers: suspend (i8042 async, full extra patch applied): 1070 (+/- 40) resume (i8042 async, full extra patch applied): 1915,84 (+/- 27) suspend (i8042 async, resume part of extra patch applied): 1050 (+/- 34) First, It looks like the suspend speedup was related to marking i8042 as "async". Since the serio devices, which are the i8042's children, were also "async" (just like in all of the tests before), this means that the speedup resulted from removing a suspend stall caused by a sync parent of async children (i8042 and serio, respectively, in this case). However, the suspend part of the extra patch doesn't help really. In fact it even makes things worse. So, I still think the resume part of the extra patch is definitely useful, but the suspend part of it is not. IOW, it's worth running async resumes upfront, but it's not worth running async suspends upfront. 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 16:40 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? 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 16:50 On Friday 18 December 2009, Alan Stern wrote: > On Fri, 18 Dec 2009, Rafael J. Wysocki wrote: > > > I didn't manage to do that, but I was able to mark sd and i8042 as async and > > see the impact of this. > > Apparently this didn't do what you wanted. In the nx6325 > sd+i8042+async+extra log, the 0:0:0:0 device (which is a SCSI disk) was > suspended by the main thread instead of an async thread. Hm, that's odd, because there's a noticeable time difference between the two cases in which the sd is sync and async. I'll look into it further. > There's an important point I neglected to mention before. Your logs > don't show anything for devices with no suspend callbacks at all. > Nevertheless, these devices sit on the device list and prevent other > devices from suspending or resuming as soon as they could. Unless they are async, that is. > For example, the fingerprint sensor (3-1) took the most time to resume. > But other devices were delayed until after it finished because it had > children with no callbacks, and they delayed the devices following > them in the list. > > What would happen if you completed these devices immediately, as part > of the first pass? OK. How do the PM core is supposed to check if a device has null suspend and resume? Check all of the function pointers in the first pass? 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 17:30 On Saturday 19 December 2009, Rafael J. Wysocki 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? Wait, if you look at the logs at http://www.sisk.pl/kernel/data/nx6325/ http://www.sisk.pl/kernel/data/wind/ you'll see that the i8042 suspend is called before any ACPI devices are suspended anyway. In fact, it is suspended right after its serio children which is very early in the suspend sequence. So, it seems, if there were any problems with i8042 vs ACPI, we'd experience them anyway. 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 17:50
On Dec 19, 2009, at 2:29 PM, "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > On Saturday 19 December 2009, Rafael J. Wysocki 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? > > Wait, if you look at the logs at > > http://www.sisk.pl/kernel/data/nx6325/ > http://www.sisk.pl/kernel/data/wind/ > > you'll see that the i8042 suspend is called before any ACPI devices > are > suspended anyway. In fact, it is suspended right after its serio > children > which is very early in the suspend sequence. Right, and we do want to "suspend" i8042 (well, reset to the initial state we found it at bootup) before touching ACPI. If i8042 is async, given the fact that psmouse reset takes a long time, it is possible that we start suspending PNP before we are done with i8042. -- > 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/ |