Hi! > > Okay, I'm little out of time now, and I do not understand 2 and 3 in > > the series. > > Well ... > > > > Make swsusp use memory bitmaps to store its internal information during the > > > resume phase of the suspend-resume cycle. > > > > > > If the pfns of saveable pages are saved during the suspend phase instead of > > > the kernel virtual addresses of these pages, we can use them during the resume > > > phase directly to set the corresponding bits in a memory bitmap. Then, this > > > bitmap is used to mark the page frames corresponding to the pages that were > > > saveable before the suspend (aka "unsafe" page frames). > > > > > > Next, we allocate as many page frames as needed to store the entire suspend > > > image and make sure that there will be some extra free "safe" page frames for > > > the list of PBEs constructed later. Subsequently, the image is loaded and, > > > if possible, the data loaded from it are written into their "original" page frames > > > (ie. the ones they had occupied before the suspend). The image data that > > > cannot be written into their "original" page frames are loaded into "safe" page > > > frames and their "original" kernel virtual addresses, as well as the addresses > > > of the "safe" pages containing their copies, are stored in a list of PBEs. > > > Finally, the list of PBEs is used to copy the remaining image data into their > > > "original" page frames (this is done atomically, by the architecture-dependent > > > parts of swsusp). > > > > So... if page in highmem is allocated during resume, you'll still need > > to copy it during assembly "atomic copy", right? > > No. It can be copied before the assembly gets called, because we are in the > kernel at that time which certainly is not in the highmem. :-) Ahha, okay, nice trick. > > Unfortunately, our assembler parts can't do it just now...? > > No, they can't, but that just isn't necessary. During the resume we create > two lists of PBEs - one for "normal" pages, and one for highmem pages. The > first one is handled by the "atomic copy" code as usual, but the second one > may be handled by some C code a bit earlier. I'm still not sure if highmem support is worth the complexity -- I hope highmem dies painful death in next 3 weeks or so. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
