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]
Date:	Sat, 11 Sep 2010 14:12: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: Avoid hitting OOM during preallocationof memory

Hello,

Sorry for the late reply. I have been busy the past few days.

On 08/09/10 05:34 PM, Rafael J. Wysocki wrote:
> On Wednesday, September 08, 2010, M. Vefa Bicakci wrote:
>> [snip]
>>
>> I should note a few things though,
>>
>> 1) I don't think I ever changed /sys/power/image_size, so we can rule out the
>> possibility of that option changing the results.
> 
> Can you please check what value is there in this file?

It contains 524288000, so I think it is set to 500 MB. I believe that this is
the default value, but I am not sure.

>> 2) With the patch below, for the *first* hibernation operation, the computer
>> enters a "thoughtful" state without any disk activity for 6-8 (maybe 10)
>> seconds after printing "Preallocating image memory". It works properly after
>> the wait however.
> 
> That probably is a result of spending time in the memory allocator trying to
> reduce the size of the image as much as possible.

I am not sure if this is a new thing with the new patch, but the behavior
seems to continue with the later hibernation operations too, not just the
first one. I haven't confirmed if I really didn't realize the problem in
the previous version of the patch, but it is very possible that I didn't
realize it since I used to automate my tests. (I didn't automate my tests
this time.)

However, considering that the kernel needs to worry about compacting 1500 MB
of data when hibernating with my tmpfs-is-full system, I guess these wait
times are normal, even though a bit inconvenient.

>> [snip]
> 
>> 4) I made sure that I was not being impatient with the previous snapshot.c
>> patch, so I tested that on its own once again, and I confirmed that hibernation
>> hangs with the older version of the snapshot.c patch.
>>
>> I am very happy that we are getting closer to a solution. Please let me know
>> if there is anything I need to test further.
> 
> Below is the patch I'd like to apply.  It should work just like the previous
> one (there are a few fixes that shouldn't affect the functionality in it), but
> please test it if you can.

I am happy to report that it works properly by only itself when applied to
a clean 2.6.35.4 tree. I haven't had any problems (aside from the "thoughtful
state" issue I mentioned above) with my 6 consecutive hibernation attempts.

> I think the slowdown you saw in 2) may be eliminated by increasing the
> image_size value, so I'm going to prepare a patch that will compute the
> value automatically during boot so that it's approximately 50% of RAM.

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.

> 
> Thanks,
> Rafael

I really appreciate your help. Thanks a lot!

M. Vefa Bicakci

> [patch snipped]
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ