From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937312AbXGTWOY (ORCPT ); Fri, 20 Jul 2007 18:14:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761836AbXGTWOP (ORCPT ); Fri, 20 Jul 2007 18:14:15 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:40164 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761414AbXGTWOO (ORCPT ); Fri, 20 Jul 2007 18:14:14 -0400 From: "Rafael J. Wysocki" To: david@lang.hm Subject: Re: [linux-pm] Re: Hibernation considerations Date: Sat, 21 Jul 2007 00:22:02 +0200 User-Agent: KMail/1.9.5 Cc: Jim Crilly , Milton Miller , linux-pm , LKML , Alan Stern , "Huang, Ying" , Jeremy Maitin-Shepard References: <200707202343.29307.rjw@sisk.pl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707210022.03205.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Friday, 20 July 2007 23:39, david@lang.hm wrote: > On Fri, 20 Jul 2007, Rafael J. Wysocki wrote: > > > On Friday, 20 July 2007 17:36, david@lang.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 ;-) Wouldn't that cause the OOM killer to act, in some cases? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth