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.

Con