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
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
