Re: Autoregulate swappiness & inactivation

[FabF]

On Fri, 2004-07-09 at 03:05, Con Kolivas wrote:
> FabF wrote:
> > Con,
> > 	What's interesting is try_to_free_pages comment :
> > 
> > " the zone may be full of dirty or under-writeback pages, which this
> >  * caller can't do much about.  We kick pdflush and take explicit naps
> > in the
> >  * hope that some of these pages can be written.  But if the allocating
> > task..."
> > 
> > 	I mean do we have high activity profile of that side of the kernel when
> > bringing up some big application to life ?
> > 	Does work consist here in 50% out, 50% in (time) ? Your anticipation
> > algorithm can help the "in" side but maybe we can optimize yet the "out"
> > side.btw, I'm surprised to see autoswappiness so far in fx tree:
> > 
> > page_reclaim
> > 	try_to_free_pages
> > 		shrink_caches
> > 			shrink_zone
> > 				refill_inactive_zone
> > 					auto_swap calculation
> > 
> > 
> > IOW, does such parameter could not involve more decisions ?
> 
> If you put it that way, yes - it would classify as duct tape. However 
> the code already acted based upon mapped_ratio which is pretty much all 
> this patch does. Folded in in that sample patch I sent out earlier you 
> can see that all it does is acted on mapped_ratio in a different manner 
> so it's not really an extra layer at all.
> 
> -	swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
> +	vm_swappiness = mapped_ratio * 150 / 100;
> +	vm_swappiness = vm_swappiness * vm_swappiness / 150;
> +	swap_tendency = distress + vm_swappiness;

Here's an easy benchmark to demonstrate problem :
1.Run Mozilla
2.Minimize
3=>Mozilla Resident Size (mrs) : 24Mb
4.Run updatedb
5.=>mrs : 15Mb
6.updatedb ends up
7.mrs doesn't move at all (yes, it goes down as I'm typing this msg :)).

So my question is :
Don't we have a way to say "whose pages were reclaimed from and
 reattribute its" ? (having in mind memory status per se).
IOW flushing (I guess it's pdflush relevant ? ) do work for dead
processes but doesn't care about applications alive...

Regards,
FabF

> 
> Con
> 
> > Regards,
> > FabF

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/