Con Kolivas wrote:

Rik van Riel wrote:

quoted

On Mon, 2 Aug 2004, Con Kolivas wrote:

quoted

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