Messages in this thread | | | From | Con Kolivas <> | Subject | Re: shrink_all_memory tweaks (was: Re: Userland swsusp failure (mm-related)) | Date | Mon, 10 Apr 2006 09:23:23 +1000 |
| |
On Monday 10 April 2006 06:36, Rafael J. Wysocki wrote: > Still I've been doing a crash course in mm internals recently and I can say > a bit more about your patch now. ;-)
Great. > > First, I agree that using balance_pgdat() for freeing memory by swsusp is > overkill, so the removal of its second argument seems to be a good idea to > me. However, I'd rather avoid modifying struct scan_control and > shrink_zone() and reimplement the shrink_zone()'s logic directly in > shrink_all_memory(), with some modifications (eg. we can explicitly avoid > shrinking of the active list until we decide it's worth it) -- or we can > define a separate function for this purpose.
I was trying to reuse as much code as possible.
> Second, there are a couple of details I'd do in a different way. For > example I think we should call shrink_slab() with the non-zero first > argument (otherwise it'll use SWAP_CLUSTER_MAX)
Sounds good.
> and instead of setting > zone->prev_priority to 0 I'd set vm_swappiness to 100 temporarily > (or maybe l'd left it to the user to set swappiness before suspend?).
Probably can't rely on just the user setting. Setting priority to 0 is explicit and overrides any swappiness setting which is a tunable. Priority will recover by itself unlike swappiness which needs to be set and reset.
> Also I think we can try to avoid slab shrinking until we start to shrink > the active zone or IOW until we can't get any more pages from the inactive > list alone.
I tried that and it didn't shrink enough, but then that's because of the SWAP_CLUSTER_MAX limit you mentioned above. But slab can be massive if you do for example a lot of 'find's and shrinking slab doesn't affect the user experence as much as shrinking the active/inactive lists.
> If you don't mind, I'll try to rework your patch a bit in accordance with > the above remarks in the next couple of days.
By all means :)
-- -ck - 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/
| |