Messages in this thread |  | | | Date | Mon, 02 Aug 2004 15:13:40 +1000 | | From | Con Kolivas <> | | Subject | Re: [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] |  |