Hi. On Wednesday 09 August 2006 19:52, Rafael J. Wysocki wrote: > Hi, > > Currently swsusp handles highmem in a simplistic way, by trying to store a > copy of each saveable highmem page in the "normal" memory before creating > the suspend image. These copies are then copied once again before saving, > because they are treated as any other non-highmem pages with data. For > this reason, to save one highmem page swsusp needs two free pages in the > "normal" memory, so on a system with high memory it is practically > impossible to create a suspend image above 400 kilobytes. Moreover, if > there's much more highmem than the "normal" memory in the system, it may be > impossible to suspend at all due to the lack of space for saving > non-freeable highmem pages. > > This limitation may be overcome in a satisfactory way if swsusp does its > best to store the copies of saveable highmem pages in the highmem itself. > However, for this purpose swsusp has to be taught to use pfns, or (struct > page *) pointers, instead of kernel virtual addresses to identify memory > pages. Yet, if this is to be implemented, we can also attack the minor > problem that the current swsusp's internal data structure, the list of page > backup entries (aka PBEs), is not very efficient as far as the memory usage > is concerned. > > This issue can be addressed by replacing the list of PBEs with a pair of > memory bitmaps. Still, to remove the list of PBEs completely, we would > have to make some complicated modifications to the architecture-dependent > parts of the code which would be quite undesirable. However, we can use > the observation that memory is only a limiting resource during the suspend > phase of the suspend-resume cycle, because during the resume phase > many image pages may be loaded directly to their "original" page frames, so > we don't need to keep a copy of each of them in the memory. Thus the list > of PBEs may be used safely in the last part of the resume phase without > limitting the amount of memory we can use. > > The following series of patches introduces the memory bitmap data > structure, makes swsusp use it to store its internal information and > implements the improved handling of saveable highmem pages. > > Comments welcome. Thanks for the reminder. I'd forgotten half the reason why I didn't want to make Suspend2 into incremental patches! You're a brave man! Nigel -- while (1) { size=$RANDOM * 65536 + 1 dd if=/dev/random bs=1 count=$size | patch -p0-b make && break }
Attachment:
pgp72VQRh8zkc.pgp
Description: PGP signature
- Follow-Ups:
- Re: [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem
- From: Pavel Machek <[email protected]>
- Re: [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem
- References:
- [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem
- From: "Rafael J. Wysocki" <[email protected]>
- [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem
- Prev by Date: Re: [PATCH] ReiserFS: Make sure all dentries refs are released before calling kill_block_super()
- Next by Date: Re: [RFC][PATCH -mm 2/5] swsusp: Use memory bitmaps during resume
- Previous by thread: Re: [RFC][PATCH -mm 3/5] swsusp: Fix handling of highmem
- Next by thread: Re: [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem
- Index(es):