Re: [PATCH 5/5] PM/Hibernate: Do not release preallocated memory unnecessarily (rev. 2)

On Sunday 16 August 2009, Wu Fengguang wrote:

On Wed, May 06, 2009 at 07:05:09AM +0800, Rafael J. Wysocki wrote:

quoted

On Tuesday 05 May 2009, Wu Fengguang wrote:

quoted

On Mon, May 04, 2009 at 08:22:38AM +0800, Rafael J. Wysocki wrote:

quoted

From: Rafael J. Wysocki <redacted>

Since the hibernation code is now going to use allocations of memory
to create enough room for the image, it can also use the page frames
allocated at this stage as image page frames.  The low-level
hibernation code needs to be rearranged for this purpose, but it
allows us to avoid freeing a great number of pages and allocating
these same pages once again later, so it generally is worth doing.

[rev. 2: Change the strategy of preallocating memory to allocate as
 many pages as needed to get the right image size in one shot (the
 excessive allocated pages are released afterwards).]

Rafael, I tried out your patches and found doubled memory shrink speed!

[  579.641781] PM: Preallocating image memory ... done (allocated 383900 pages, 128000 image pages kept)
[  583.087875] PM: Allocated 1535600 kbytes in 3.43 seconds (447.69 MB/s)

Unfortunately, I'm observing a regression and a huge one.

On my Atom-based test box with 1 GB of RAM after a fresh boot and starting X
with KDE 4 there are ~256 MB free.  To create an image we need to free ~300 MB
and that takes ~2 s with the old code and ~15 s with the new one.

It helps to call shrink_all_memory() once with a sufficiently large argument
before the preallocation.

The 10 fold slowdown may be related to swapping IO:

I guess it is.

shrink_all_memory() tends to be reclaiming less anon pages.

Is this box running on SSD? (Which can be slow on random writes.)

No, on a normal spinning-plate HDD (2.5'').

Thanks,
Rafael