> 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=...
>>>>> 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/hea...
>>>>> (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?
