lkml.org 
[lkml]   [2004]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Autoregulate swappiness & inactivation
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.099 / U:0.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site