Re: [RFC][PATCH -mm] swsusp: use less memory during resume

["Rafael J. Wysocki" <rjw@sisk.pl>]

Hi,

On Tuesday 18 April 2006 15:07, Nigel Cunningham wrote:
> On Tuesday 18 April 2006 21:19, Rafael J. Wysocki wrote:
> > Currently during resume swsusp puts the image data in the page frames that
> > don't conflict with the original locations of the data (ie. the locations
> > the data will be put in when the saved system state is restored from the
> > image). These page frames are considered as "safe" and the other page
> > frames are treadet as "unsafe".
> >
> > Of course we cannot force the memory allocator to allocate "safe" pages
> > only, so if an "unsafe" page is allocated, swsusp treats it as an "eaten
> > page" and attempts to allocate another page in the hope that it'll be
> > "safe" etc. swsusp tries to allocate as many "safe" pages as necessary to
> > store the image data, so it "eats" a considerable number of "unsafe" pages
> > in the process.  Next, it reads the image and puts the data into the
> > allocated "safe" pages.  Finally, the data are copied to their "original"
> > locations.
> >
> > This approach, although it works nicely, is quite inefficient from the
> > memory utilization point of view and it also turns out to be unnecessary. 
> > Namely, for each "unsafe" page frame returned by the memory allocator
> > there's exactly one page in the image that finally should be placed in this
> > page frame. Therefore we can put the right data into this page frame as
> > soon as they're read from the image and we won't have to copy these data
> > later on.  This way we'll only need to allocate as many pages as necessary
> > to store the image data and we won't have to "eat" the "unsafe" pages.
> >
> > The appended patch implements this idea.  It makes swsusp allocate as
> > many pages as it'll need to store the data read from the image in one
> > shot, creating a list of allocated "safe" pages, and uses the observation
> > that all pages allocated by swsusp are marked with the PG_nosave and
> > PG_nosave_free flags set.  Namely, when it's about to read a page, it
> > checks whether the page frame corresponding to the "original" location of
> > this page has been allocated (ie. if the page frame has the PG_nosave and
> > PG_nosave_free flags set) and if so, it reads the page directly into this
> > page frame.  Otherwise it uses an allocated "safe" page from the list to
> > store the data that will be copied to their "original" location later on.
> >
> > On my box this patch allows us to save as many as approx. 90000 page
> > copyings and 90000 (at least - probably twice as many, because it's an
> > x86_64 box) page allocations for an image of approx. 100000 of pages.  Also
> > it will allow us to read images greater than 50% of the normal zone (when
> > we learn how to create them ;-)).
> 
> Haven't looked at the patch itself, but this sounds like a great idea. I 
> wonder though, won't the 50% limit still apply, because you'll still have to 
> make an atomic copy to start with (unless you figure out which pages aren't 
> going to change and therefore don't need to be atomically copied)?

You are right, and I'm going to figure out which pages won't change.  I think
I have some good candidates. ;-)

Greetings,
Rafael
-
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/