public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC] Asynchronous suspend/resume - test results
@ 2009-12-21  0:40 Rafael J. Wysocki
  2009-12-21  7:25 ` [linux-pm] " Nigel Cunningham
  2009-12-21 20:10 ` Alan Stern
  0 siblings, 2 replies; 19+ messages in thread
From: Rafael J. Wysocki @ 2009-12-21  0:40 UTC (permalink / raw)
  To: pm list
  Cc: ACPI Devel Maling List, LKML, Linus Torvalds, Alan Stern,
	Dmitry Torokhov

Hi,

After the Dmitry's suggestion to use PSMOUSE_CMD_RESET_DIS during suspend
(and analogously for atkbd), I found that it reduced the suspend time
significantly and changed the picture quite a bit.  For this reason I re-ran
the async suspend and resume tests on the nx6325 and Wind U100.

This time I marked the following devices as "async":
- all USB devices (including interfaces and endpoints)
- ACPI battery
- sd and its parent
- serio and i8042
- all PCI devices (including bridges)
for all tests (except for the sync suspend/resume test).

The results are as follows (all times in milliseconds):

			HP nx6325	MSI Wind U100

sync suspend		1391 (+/- 32)	 703 (+/- 26)
sync resume		3027 (+/- 6)	3562 (+/- 25)

async suspend		1306 (+/- 66)	 659 (+/- 22)
async resume		2809 (+/- 250)	3564 (+/- 35)

async "upfront" suspend	1038 (+/- 46)	 564 (+/- 50)
async "upfront" resume	1783 (+/- 7)	1925 (+/- 41)

where the "upfront" versions are with all of the async threads started in an
additional loop over dpm_list before the main "sync" suspend/resume loop.

The raw data are at:

http://www.sisk.pl/kernel/data/async-suspend-new.pdf
http://www.sisk.pl/kernel/data/nx6325/
http://www.sisk.pl/kernel/data/wind/

(hopefully this time I didn't make mistakes in the file names).

The data seem to suggest that "normal" async suspend and resume may be a little
(10% - 20%) faster than sync suspend and resume, but not as much as the
versions where all of the async threads had been started before the main
suspend (resume) thread began handling the "sync" devices.

IMO it also is worth noting that the "async upfront suspend" time on the Wind
is pretty close to the suspend time of the slowest device (~ .5 s).  The same
applies to the "async upfront resume" time on the Wind (the slowest device
resumes in ~1.5 s) and the "async upfront suspend" time on the nx6325 (the
slowest device suspends in ~1 s).  So, it looks like with the above set of
async devices we can approach pretty close to the achievable limit on both
test boxes.

I'm not sure what the next step should be at this point.  To me, the picture is
quite clear now, but perhaps we ought to run more tests on some other machines
or something.  Please let me know what you think.

Rafael

^ permalink raw reply	[flat|nested] 19+ messages in thread
end of thread, other threads:[~2010-01-04 17:17 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-21  0:40 [RFC] Asynchronous suspend/resume - test results Rafael J. Wysocki
2009-12-21  7:25 ` [linux-pm] " Nigel Cunningham
2009-12-21  7:35   ` Dmitry Torokhov
2009-12-21 19:58   ` Maxim Levitsky
2009-12-21 20:04     ` Nigel Cunningham
2009-12-23 20:46   ` Rafael J. Wysocki
2009-12-24  2:32     ` Nigel Cunningham
2009-12-24 22:10       ` Rafael J. Wysocki
2009-12-25 20:57         ` Nigel Cunningham
2009-12-26 21:33           ` Rafael J. Wysocki
2009-12-26 22:03             ` Nigel Cunningham
2009-12-27 14:20               ` Rafael J. Wysocki
2009-12-21 20:10 ` Alan Stern
2009-12-21 20:36   ` Rafael J. Wysocki
2009-12-21 20:54     ` Alan Stern
2009-12-21 23:00     ` Linus Torvalds
2009-12-23 20:35     ` Rafael J. Wysocki
2010-01-02 21:28       ` [Update] " Rafael J. Wysocki
2010-01-04 17:17         ` Jesse Barnes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox