Re: [linux-pm] [PATCH] Hibernate: Implement readahead when resuming

[Martin Steigerwald]

Hi Nigel and Rafael,

Am Samstag 25 September 2010 schrieb Nigel Cunningham:
> Add support for submitting reads before they're needed. This greatly
> improves the speed of resuming:
> 
> From
> 
> PM: Image read at 66 MB/s.
> 
> to
> 
> PM: Image read at 229 MB/s.
> 
> ...and removes the need for the sync_read flag.

So

martin@shambhala:~/Computer/Shambhala/Kernel/2.6.36/tuxonice-head> git 
branch -av | grep for-rafael
* for-rafael                      d4e7490 Hibernate: Implement readahead 
when resuming
  remotes/origin/for-rafael       d4e7490 Hibernate: Implement readahead 
when resuming

martin@shambhala:~> cat /proc/version
Linux version 2.6.36-rc5-tp42-hibernate-accel-vmembase-0-00135-gd4e7490-
dirty (martin@shambhala) (gcc version 4.4.5 20100728 (prerelease) (Debian 
4.4.4-8) ) #1 PREEMPT Sat Sep 25 18:02:02 CEST 2010

basically seems to work.

But

> Signed-off-by: Nigel Cunningham <nigel@xxxxxxxxxxxx>
> ---
>  kernel/power/block_io.c |   97
> ++++++++++++++++++++++++++++++++++++++++++++--- kernel/power/power.h  
>  |    4 --
>  kernel/power/snapshot.c |    5 --
>  kernel/power/swap.c     |    2 -
>  4 files changed, 91 insertions(+), 17 deletions(-)
> 
> diff --git a/kernel/power/block_io.c b/kernel/power/block_io.c
> index fc2e05d..5a13f80 100644
> --- a/kernel/power/block_io.c
> +++ b/kernel/power/block_io.c
[...]
> +	if (!offset) {
> +		printk("Offset zero - no more readahead.\n");
> +		more_readahead = 0;
> +		return 0;
> +	}
> +
> +	printk("(1) Submitting readahead of sector %llu to page %p.\n",
> +			offset, ra_page);

and

> +	if (!readahead_list_head) {
> +		printk("No readahead left. Returning -EFAULT.\n");
>  		return -EFAULT;
> -	return hib_bio_read_page(offset, buf, sync);
> +	}
> +
> +	printk("Waiting on readahead of page %p.\n", readahead_list_head);

should be made optional - activatable via a debug switch - before this 
gets merged, cause it displays a lots of these on resuming which takes 
some time in itself.

I tried 5 times:

- one with just kdm started worked nicely and really rather fast!

- four with a full blown KDE 4.5.1 session with OpenGL compositing
  - one seemed to hang prior to reinitializing the Radeon KMS DRM setup
  - three other worked just fine

I do not think that the hang is related to your changes, Nigel. The kernel 
remained stuck at the lower initial resolution and didn't seem to 
initialize the radeon KMS framebuffers at 1400x1050 properly. I didn't see 
this with 2.6.35 and userspace software suspend.

Writing and reading seems to be way faster than with userspace software 
suspend, I didn't compare with unpatched in kernel suspend. But I do not 
seem to get any numbers printed:

shambhala:~> grep "Image read" /var/log/syslog
shambhala:~#1> dmesg | grep "Image read"        
shambhala:~#1> dmesg | grep "Image writ"
shambhala:~#1> grep "Image writ" /var/log/syslog
shambhala:~#1>

The machine seems to return more quickly to an usable state. Does in 
kernel suspend save larger images? I am especially surprised as I use 
compression with userspace software suspend which I thought should speed 
up writing the image. It feels that in kernel suspend with patches from 
you, Nigel, seems to outdo userspace software suspend by quite some 
margin.

I have a quite high setting for userspace software suspend image size:

  1 # /etc/uswsusp.conf(8) -- Configuration file for s2disk/s2both·
  2 resume device = /dev/sda2
  3 compress = y
  4 early writeout = y
  5 image size = 1500
  6 shutdown method = halt

Still the machine crawls on resume for about 30 seconds or a minute before 
coming into a usable state. With patched in kernel suspend this wait for 
responsivity seems to have cut down to about 10-15 seconds.

Please note: I didn't actually measure anything of this, this is just 
subjective impressions so far. Before measuring, I think I should disable 
those debug outputs I mentioned above ;).

The ThinkPad T42 I am testing on has 2 GiB RAM. Swap is about 4 GB.

No long term observations so far. I will report how it goes.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Attachment: signature.asc
Description: This is a digitally signed message part.