lkml.org 
[lkml]   [2007]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-pm] Re: Hibernation considerations
    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 ;-)

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

    \
     
     \ /
      Last update: 2007-07-20 23:49    [W:3.302 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site