lkml.org 
[lkml]   [2009]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC][PATCH 4/5] PM/Hibernate: Rework shrinking of memory
    Date
    On Thursday 07 May 2009, Rafael J. Wysocki wrote:
    > On Thursday 07 May 2009, Nigel Cunningham wrote:
    > > Hi.
    >
    > Hi,
    >
    > > On Thu, 2009-05-07 at 00:44 +0200, Rafael J. Wysocki wrote:
    > > > From: Rafael J. Wysocki <rjw@sisk.pl>
    > > >
    > > > Rework swsusp_shrink_memory() so that it calls shrink_all_memory()
    > > > just once to make some room for the image and then allocates memory
    > > > to apply more pressure to the memory management subsystem, if
    > > > necessary.
    > > >
    > > > Unfortunately, we don't seem to be able to drop shrink_all_memory()
    > > > entirely just yet, because that would lead to huge performance
    > > > regressions in some test cases.
    > >
    > > I know it doesn't fit with your current way of doing things, but have
    > > you considered trying larger order allocations as a means of getting
    > > memory freed?
    >
    > Actually, I was thinking about that. What's your experience with this
    > approach?
    >
    > > I have code in tuxonice_prepare_image.c (look for extra_pages_allocated) that
    > > might be helpful for this purpose.
    >
    > OK, thanks. I'll have a look at it.

    I have tried it, but the results are even worse than with 0-order allocations
    only.

    So far, I have got the best results with shrink_all_memory() called once and
    followed by allocating as much memory as we want to be free using 0-order
    allocations. Like in this patch. :-)

    Thanks,
    Rafael


    \
     
     \ /
      Last update: 2009-05-07 22:05    [W:0.022 / U:92.796 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site