Re: [RFC][PATCH] swsusp: do not use higher order memory allocations [update]

[Rafael J. Wysocki]

Hi,

On Monday, 31 of January 2005 00:19, Rafael J. Wysocki wrote:
> Hi,
> 
> The following patch is (yet) an(other) attempt to eliminate the need for using higher
> order memory allocations on resume.  It accomplishes this by replacing the array
> of page backup entries with a list, so it is only necessary to allocate individual
> memory pages.  This approach makes it possible to avoid relocating many memory
> pages on resume (as a result, much less memory is used) and to simplify
> the assembly code that restores the image.
> 
> The patch is a complement to the patch that I sent some time ago as "swsusp: do not
> use higher order memory allocations on suspend".  It is against 2.6.11-rc2 - on top
> of the previous patch and on top of the "x86_64: Speed up suspend" patch which are
> availble at:
> http://www.sisk.pl/kernel/patches/2.6.11-rc2/swsusp-use-list-suspend-v2.patch
> and at:
> http://www.sisk.pl/kernel/patches/2.6.11-rc2/x86_64-Speed-up-suspend.patch
> respectively.  The patch itself is available at:
> http://www.sisk.pl/kernel/patches/2.6.11-rc2/swsusp-use-list-resume-v1.patch
> and there is a consolidated patch against 2.6.11-rc2 at:
> http://www.sisk.pl/kernel/patches/2.6.11-rc2/2.6.11-rc2-swsusp-use-list.patch

I have updated the patches to include a bugfix from Pavel Machek (thanks, Pavel!).
Affected are the "suspend" patch and the "consolidated" patch.  The updated patches
are available at:
http://www.sisk.pl/kernel/patches/2.6.11-rc2/swsusp-use-list-suspend-v3.patch
http://www.sisk.pl/kernel/patches/2.6.11-rc2/2.6.11-rc2-swsusp-use-list-v2.patch
respectively.  The other patches remain unchanged.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/