lkml.org 
[lkml]   [2009]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Async suspend-resume patch w/ completions (was: Re: Async suspend-resume patch w/ rwsems)
    Date
    On Saturday 19 December 2009, Dmitry Torokhov wrote:
    > On Dec 19, 2009, at 1:33 PM, "Rafael J. Wysocki" <rjw@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


    \
     
     \ /
      Last update: 2009-12-20 00:13    [W:0.038 / U:30.128 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site