Re: [RFC] Asynchronous suspend/resume - test results

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Monday 21 December 2009, Rafael J. Wysocki wrote:
> On Monday 21 December 2009, Alan Stern wrote:
> > On Mon, 21 Dec 2009, Rafael J. Wysocki wrote:
...
> > You should also make SCSI targets and hosts async.  Hosts are added in
> > drivers/scsi/hosts.c:scsi_add_host_with_dma() (in 2.6.32 this was
> > named scsi_add_host()).  Targets are added in
> > drivers/scsi/scsi_sysfs.c:scsi_target_add().  And for thoroughness,
> > SCSI devices are added in scsi_sysfs_add_sdev() in the same file.
> 
> Thanks a lot for the pointers.

I put device_enable_async_suspend() in all of these places and that resulted in
major reduction of suspend time without starting the async threads upfront.
Now, however, starting them upfront helps only a little, within the standard
deviation from the "non-upfront" case.

In turn, resume _without_ starting the async threads upfront makes a little
sense on my test boxes.  In fact, it only helped on the nx6325 and made things
worse on the other two (I added the results from Toshiba Portege R500, but it
has the same chipset as the Wind U100, ie. ICH7).

The results are as follows:

			HP nx6325	MSI Wind U100	Toshiba Portege R500

sync suspend		1357 (+/- 35)	 656 (+/- 50)	 889 (+/- 29)
sync resume		3027 (+/- 6)	3372 (+/- 30)	4552 (+/- 35)

async suspend		1053 (+/- 50)	 490 (+/- 42)	 620 (+/- 52)
async resume		2291 (+/- 7)	3406 (+/- 52)	4557 (+/- 26)

async "upfront" suspend	1040 (+/- 35)	 476 (+/- 9)	 585 (+/- 29)
async "upfront" resume	1787 (+/- 7)	1724 (+/- 48)	1990 (+/- 25)

The raw data are at
http://www.sisk.pl/kernel/data/async-suspend-updated.pdf
http://www.sisk.pl/kernel/data/r500/
http://www.sisk.pl/kernel/data/nx6325/
http://www.sisk.pl/kernel/data/wind/

and the previous results were moved into
http://www.sisk.pl/kernel/data/091220/

The patches used in the testing are in my async branch at
http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-2.6.git;a=shortlog;h=refs/heads/async
The patches in this branch are not for upstream, but it's on top of the 
linux-next branch containing patches for the 2.6.34 merge window.

...
> > Although USB host controllers aren't the longest-running devices to
> > resume, they do tend to be on the longest paths.  Speeding them up
> > would help.  One change you could try is in the patch below.  
> > Currently when a controller has to be reset, the root hub beneath it is
> > also reset and then re-suspended.  However there's no reason to suspend
> > it if the PM core is only going to resume it a little bit later.  The
> > patch gets rid of the unnecessary suspend.  Note: I haven't tested it.
> 
> OK, I'll try it.

Unfortunately it breaks the second suspend (suspend process returns error code
and says that the controller was not suspended, more or less).

Rafael