[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200912180251.22655.rjw@sisk.pl>
Date: Fri, 18 Dec 2009 02:51:22 +0100
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Alan Stern <stern@...land.harvard.edu>,
Zhang Rui <rui.zhang@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: Async suspend-resume patch w/ completions (was: Re: Async suspend-resume patch w/ rwsems)
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). Nevertheless the resume part of the "extra"
patch worked in both cases and worked better than without the two additional
"async" devices.
To me, this means that the suspend part of the "extra" patch is not really
useful. However, the resume part of it is _very_ useful, so I'd like to add
that part only to the async patchset. The explanation why it helps so much
is also straightforward to me. Namely, if slow async devices are last to
resume, then without the "extra" patch they need to wait for all of the
preceding sync devices and the speedup from executing their resume routines
asynchronously is very limited. Now, with the "extra" patch their resume
routines start as soon as their parents complete resuming and that may be
early enough for the speedup to be significant.
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists