[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <200608091152.49094.rjw@sisk.pl>
Date: Wed, 9 Aug 2006 11:52:49 +0200
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Pavel Machek <pavel@....cz>, Linux PM <linux-pm@...l.org>
Subject: [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem
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.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists