Re: [PATCH] token based thrashing control

[Song Jiang <sjiang@CS.WM.EDU>]

When there is memory competition among multiple processes,
Which process grabs the token first is important.
A process with its memory demand exceeding the total
ram gets the token first and finally has to give it up 
due to a time-out would have little performance gain from token,
It could also hurt others. Ideally we could make small processes
more easily grab the token first and enjoy the benifis from
token. That is, we want to protect those that are deserved to be
protected. Can we take the rss or other available memory demand
information for each process into the consideration of whether 
a token should be taken, or given up and how long a token is held.  
  Song

On Mon, 2 Aug 2004, Con Kolivas wrote:

> 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
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>