Messages in this thread | | | From | Con Kolivas <> | Subject | Re: [PATCH] mm: swsusp shrink_all_memory tweaks | Date | Sat, 25 Mar 2006 02:30:07 +1100 |
| |
On Saturday 25 March 2006 02:16, Rafael J. Wysocki wrote: > On Friday 24 March 2006 08:07, Con Kolivas wrote: > > On Tuesday 21 March 2006 05:46, Rafael J. Wysocki wrote: > > > swsusp_shrink_memory() is still wrong, because it will always fail for > > > image_size = 0. My bad, sorry. > > > > > > The appended patch (on top of yours) should fix that (hope I did it > > > right this time). > > > > Well I discovered that if all the necessary memory is freed in one call > > to shrink_all_memory we don't get the nice updating printout from > > swsusp_shrink_memory telling us we're making progress. So instead of > > modifying the function to call shrink_all_memory with the full amount > > (and since we've botched swsusp_shrink_memory a few times between us), we > > should limit it to a max of SHRINK_BITEs instead. > > > > This patch is fine standalone. > > > > Rafael, Pavel what do you think of this one? > > In principle it looks good to me, but when I tested the previous one I > noticed shrink_all_memory() tended to return 0 prematurely (ie. when it was > possible to free some more pages). It only happened if more than 50% of > memory was occupied by application data. > > Unfortunately I couldn't find the reason.
Perhaps it was just trying to free up too much in one go. There are a number of steps a mapped page needs to go through before being finally swapped and there are a limited number of iterations over it. Limiting it to SHRINK_BITEs at a time will probably improve that.
Cheers, Con - 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/
| |