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):
 |