lkml.org 
[lkml]   [2009]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Bug #13058] First hibernation attempt fails
    On Wed, 22 Apr 2009 22:11:17 +0200
    "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

    > On Wednesday 22 April 2009, Pavel Machek wrote:
    > > Hi!
    > >
    > > > Of course, this will protect the calling task from getting oom-killed.
    > > > But it doesn't protect other tasks from getting oom-killed due to the
    > > > activity of _this_ task.
    > > >
    > > > But I think that problem already exists, and that this proposal doesn't
    > > > worsen anything, yes?
    > > >
    > > > Or is it the case that all other tasks are safely stuck in the freezer
    > > > at this time, so they won't be allocating any memory anyway?
    > >
    > > That is the idea, yes. ... but we now have more threads that are not
    > > freezable... so they may allocate the memory.
    > >
    > > Is it non-feasible to free memory without really going and allocating
    > > everything?
    >
    > The question is whether there is a point. In principle we can just go and
    > allocate as much as we need upfront. It shouldn't change anything, because
    > we resume and suspend devices after creating the image anyway.
    >
    > I think we could try to disable the OOM killer before suspend and just
    > allocate the memory for the image right before devices are suspended for the
    > first time.
    >

    It would be nice to do.

    shrink_all_memory() is simply trying to do something which page reclaim
    doesn't expect to do (free memory when there's already lots of memory
    free). Consequently it doesn't do it very well, and there's a good
    risk that changes to core reclaim will accidentally break
    shrink_all_memory().



    \
     
     \ /
      Last update: 2009-04-22 22:31    [W:0.035 / U:0.256 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site