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
