Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [linux-pm] Re: Hibernation considerations | Date | Sat, 21 Jul 2007 00:22:02 +0200 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |