lkml.org 
[lkml]   [2004]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateMon, 02 Aug 2004 15:18:52 +1000
FromCon Kolivas <>
SubjectRe: [PATCH] token based thrashing control
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:04    [from the cache]
©2003-2010