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