Re: [linux-pm] [PATCH] Hibernate: Implement readahead when resuming
From: Nigel Cunningham
Date: Sat Sep 25 2010 - 17:21:17 EST
Hi.
On 26/09/10 05:02, Martin Steigerwald wrote:
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.
Oh, I'm sorry. I completely forgot about that debugging code. Removed
now. (Note that I'm rebasing and modifying this branch like a patch
series, so you will get conflicts when you pull updates).
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>
It uses pr_debug. Do you have CONFIG_PM_DEBUG=y?
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.
All I have changed at the moment is how the image is saved. With these
patches, swap is being allocated prior to saving the image (which
shouldn't itself make a huge difference in speed), and the image is
stored in a slightly different format which lets us not have to do i/o
in batches. In addition (with this last patch), we submit the reads
before we need them.
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,
Thank you!
Nigel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/