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;

Con

> Regards,
> FabF