Messages in this thread | | | Date | Mon, 27 Feb 2006 00:56:14 +0100 | From | Pavel Machek <> | Subject | Re: [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking |
| |
On Po 27-02-06 00:38:40, Rafael J. Wysocki wrote: > On Monday 27 February 2006 00:32, Rafael J. Wysocki wrote: > > On Sunday 26 February 2006 19:53, Pavel Machek wrote: > > > > > > > I did try shrink_all_memory() five times, with .5 second delay between > > > > > > > them, and it freed more memory at later tries. > > > > > > > > > > > > I wonder if the delays are essential or if so, whether they may be shorter > > > > > > than .5 sec. > > > > > > > > > > I was using this with some success... (Warning, against old > > > > > kernel). But, as I said, I consider it ugly, and it would be better to > > > > > fix shrink_all_memory. > > > > > > > > Appended is a patch against the current -mm. > > > > [It also makes > > > > swsusp_shrink_memory() behave as documented for image_size = 0. > > > > Currently, if it states there's enough free RAM to suspend, it won't bother > > > > to free a single page.] > > > > > > Could we get bugfix part separately? > > > > Sure. Appended is the bugfix (I haven't tested it separately yet, but I think > > it's simple enough) ... > > ... and this is the workaround of the "shrink_all_memory() returns 0 prematurely" > problem (not tested separately yet). [Together these patches make my box > actually free more memory when image_size = 0.]
He he, move the workaround into mm/vmscan.c to get Andrew's attetion then attempt to push it :-))). That way
1) shrink_all_memory() will get fixed for all callers
2) you'll probably force akpm to fix it the right way :-).
Pavel
-- Feeling evil tonight. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |