Re: rss recovery

[FabF <fabian.frederick@skynet.be>]

On Sat, 2004-07-10 at 14:03, Nick Piggin wrote:
> FabF wrote:
> > Nick,
> > 	Putting some more pressure I finally saw the awaited behaviour from np
> > : rss gaining 1MB (or at least 1 byte :) : top reports 10M -> 11M )
> > directly after make was done with 10 threads.
> > 
> > But I guess it can do much better than that (IOW recover original rss).
> > Where does re-attribution takes place in np ?
> > 
> 
> I don't do any sort of preemptive RSS recovery. The pagein mechanisms
> are unchanged with my patch. The point was that mozilla no longer got
> swapped out by updatedb, isn't that what you wanted?
> 
Nick,

Your patch is great as system delves for pages without eating too much
RSS around.

I just thought about some sort of combination :

	-On one side a swapout regulation
	-But also somekind of smooth swapin operation.

Reason for this being box freeze effect after some heavy load.

I made a slight patchset which tries to do the second path.It's being
called RGR for "RSS Gradual Recovery".It works with 2 sysctl parameters
for testing :

	-swapoff_max_swapout :  It proceeds when kswapd has not reported more
than this.
	-swapoff_smooth_range : Number of pages to swap in at once.

That process uses a try_to_unuse patched version to emerge some pages
when swapout is relaxed.That stuff is done in a swap device transparent
poll method and should result in GUI application foregrounding done
quickly even after some heavy-load storm; my problem being where this
one can be called from ? As an example, I put a swapoff_smooth in
do_anonymous_page but it's not the right location I guess :))) just
wanted some place frequently called to see effects.

Of course, your help would be appreciated ;)

patchset is available from:
http://fabian.unixtech.be/ff/linux-2.6.7-mm7-rgr1.diff

Regards,
FabF