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