Rik van Riel wrote:

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.

Con