Hi. On Wednesday 19 April 2006 18:05, Rafael J. Wysocki wrote: > 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. ;-) LRU by any chance? :) Nigel
Attachment:
pgpl6RzyeHymt.pgp
Description: PGP signature
- Follow-Ups:
- Re: [linux-pm] Re: [RFC][PATCH -mm] swsusp: use less memory during resume
- From: "Rafael J. Wysocki" <[email protected]>
- Re: [linux-pm] Re: [RFC][PATCH -mm] swsusp: use less memory during resume
- References:
- [RFC][PATCH -mm] swsusp: use less memory during resume
- From: "Rafael J. Wysocki" <[email protected]>
- Re: [RFC][PATCH -mm] swsusp: use less memory during resume
- From: Nigel Cunningham <[email protected]>
- Re: [RFC][PATCH -mm] swsusp: use less memory during resume
- From: "Rafael J. Wysocki" <[email protected]>
- [RFC][PATCH -mm] swsusp: use less memory during resume
- Prev by Date: Re: [RFC][PATCH 0/11] security: AppArmor - Overview
- Next by Date: Re: sata suspend resume ...
- Previous by thread: Re: [RFC][PATCH -mm] swsusp: use less memory during resume
- Next by thread: Re: [linux-pm] Re: [RFC][PATCH -mm] swsusp: use less memory during resume
- Index(es):