Re: [PATCH] token based thrashing control

[Con Kolivas]

Con Kolivas wrote:
> Rik van Riel wrote:
>
> > On Mon, 2 Aug 2004, Con Kolivas wrote:
> >
> >
> > > We have some results that need interpreting with contest.
> > > mem_load:
> > > Kernel    [runs]    Time    CPU%    Loads    LCPU%    Ratio
> > > 2.6.8-rc2      4    78    146.2    94.5    4.7    1.30
> > > 2.6.8-rc2t     4    318    40.9    95.2    1.3    5.13
> > >
> > > The "load" with mem_load is basically trying to allocate 110% of free 
> > > ram, so the number of "loads" although similar is not a true 
> > > indication of how much ram was handed out to mem_load. What is 
> > > interesting is that since mem_load runs continuously and constantly 
> > > asks for too much ram it seems to be receiving the token most 
> > > frequently in preference to the cc processes which are short lived. 
> > > I'd say it is quite hard to say convincingly that this is bad because 
> > > the point of this patch is to prevent swap thrash.
> >
> >
> >
> > It may be worth trying with a shorter token timeout
> > time - maybe even keeping the long ineligibility ?
>
>
> Give them a "refractory" bit which is set if they take the token? Next 
> time they try to take the token unset the refractory bit instead of 
> taking the token.

Or take that concept even further; Give them an absolute refractory 
period where they cannot take the token again and a relative refractory 
bit which can only be reset after the refractory period is over.

Con

Attachment: signature.asc
Description: OpenPGP digital signature