linux-kernel - Re: [PATCH] PM / Hibernate: Make default image size depend on totalRAM size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C8E45EB.8030408@superonline.com>
Date:	Mon, 13 Sep 2010 11:40:27 -0400
From:	"M. Vefa Bicakci" <bicave@...eronline.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-pm@...ts.linux-foundation.org,
	Minchan Kim <minchan.kim@...il.com>
Subject: Re: [PATCH] PM / Hibernate: Make default image size depend on totalRAM size

On 11/09/10 06:27 PM, Rafael J. Wysocki wrote:
> On Saturday, September 11, 2010, Rafael J. Wysocki wrote:
>> On Saturday, September 11, 2010, M. Vefa Bicakci wrote:
> ...
>>>
>>> I would be glad to test that patch as well, to see if it brings speed-ups.
>>> Actually, I might test hibernation with a larger value written to
>>> /sys/power/image_size when I have time.
>>
>> I think that would improve things, as it probably is impossible to reduce the
>> image size to 500 MB on your system.
>>
>> Anyway, I'll let you know when the patch is ready.
> 
> OK, please try the patch below on top of the previous one and see if it makes
> hibernation run faster on your system.

Dear Rafael Wysocki,

I think I have good news. I took a clean 2.6.35.4 tree, and first applied
the latest version of your larger snapshot.c patch, and then the patch you
appended to your final e-mail in this thread.

Here is a comparison of the timings from a kernel without your patch, and
one with it.

=== 8< ===
Sep 11 10:22:24 debian kernel: [  499.968989] PM: Allocated 2531300 kbytes in 52.66 seconds (48.06 MB/s)
Sep 11 10:44:08 debian kernel: [  764.379131] PM: Allocated 2531308 kbytes in 143.41 seconds (17.65 MB/s)
Sep 11 10:48:41 debian kernel: [  920.626386] PM: Allocated 2531300 kbytes in 66.44 seconds (38.09 MB/s)
Sep 11 10:53:37 debian kernel: [ 1092.919140] PM: Allocated 2531316 kbytes in 81.28 seconds (31.14 MB/s)
...
Sep 13 01:26:09 debian kernel: [   94.948054] PM: Allocated 1804008 kbytes in 28.72 seconds (62.81 MB/s)
Sep 13 01:29:58 debian kernel: [  176.678880] PM: Allocated 1803992 kbytes in 34.44 seconds (52.38 MB/s)
Sep 13 01:33:48 debian kernel: [  253.336405] PM: Allocated 1804000 kbytes in 27.35 seconds (65.95 MB/s)
=== >8 ===

I didn't have your latest patch applied on September 11, and it was applied
last night.

It looks like there is a good improvement. I think the data rates look
faster on Sept. 13 because the kernel spent less time "thinking" less
while compacting the memory image. (I don't think I have changed anything
in my configuration that could affect the data rates that much.)

Is it possible to have these patches applied to the 2.6.35 tree so that
the regression I reported is fixed? Should I e-mail Greg Kroah-Hartman
about this?

Once again, thank a lot to you, Kosaki Motohiro and Minchan Kim!

M. Vefa Bicakci

> [snip patch]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/