linux-kernel - Re: [linux-pm] Re: Hibernation considerations

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: <Pine.LNX.4.64.0707201435520.5166@asgard.lang.hm>
Date:	Fri, 20 Jul 2007 14:39:39 -0700 (PDT)
From:	david@...g.hm
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Jim Crilly <jim@....dont.jablowme.net>,
	Milton Miller <miltonm@....com>,
	linux-pm <linux-pm@...ts.linuxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	"Huang, Ying" <ying.huang@...el.com>,
	Jeremy Maitin-Shepard <jbms@....edu>
Subject: Re: [linux-pm] Re: Hibernation considerations

On Fri, 20 Jul 2007, Rafael J. Wysocki wrote:

> On Friday, 20 July 2007 17:36, david@...g.hm wrote:
>> On Fri, 20 Jul 2007, Jim Crilly wrote:
>>
>>>>> has
>>>>> requested the image to be not greater than 50% of RAM.  In that case you
>>>>> have
>>>>> to free some memory _before_ identifying memory to save and you must not
>>>>> race with applications that attempt to allocate memory while you're doing
>>>>> it.
>>>>
>>>> I disagree a little bit.
>>>>
>>>> first off, only the suspending kernel can know what can be freed and what
>>>> is needed to do so (remember this is kernel internals, it can change from
>>>> patch to patch, let alone version to version)
>>>>
>>>> second, if you have a lot of memory to free, and you can't just throw away
>>>> caches to do so, you don't know what is going to be involved in freeing
>>>> the memory, it's very possilbe that it is going to involve userspace, so
>>>> you can't freeze any significant portion of the system, so you can't
>>>> eliminate all chance of races
>>>>
>>>> what you can do is
>>>>
>>>> 1. try to free stuff
>>>> 2. stop the system and account for memory, is enough free
>>>> if not goto 1
>>>>
>>>> if userspace is dirtying memory fast enough, or is just useing enough
>>>> memory that you can't meet your limit you just won't be able to suspend.
>>>>
>>>> but under any other conditions you will eventually get enough memory free.
>>>>
>>>> so try several times and if you still fail tell the user they have too
>>>> much stuff running and they need to kill something.
>>>
>>> Which would be a pretty big regression from what we have now. With the
>>> current implementation I can hibernate under virtually any workload because
>>> the freezer stops everything and there's no competition for resources.
>>
>> as long as what you are trying to save is <=50% of ram (at least with some
>> implementations). if you are trying to save more then 50% of ram with some
>> current implmenetations you just can't
>
> With some, you can't, with the others, you can. :-)
>
> The argument given was about the freezer and IMO it was valid.
>
> Why didn't you address it directly?

I thought it had been covered in other messages (with as big as this 
thread is I'm trying to avoid repeating the same thing more then a couple 
times a day :-)

there was another message talking about ways that you could reduce the 
image size without it being racy (allocate pinned memory until the 
remainder is small enough, then don't backup the pinned memory)

that's a much cleaner answer then what I was thinking, so I'll go with it 
instead ;-)

David Lang
-
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/