Re: [PATCH] token based thrashing control

[Con Kolivas <kernel@kolivas.org>]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

Andrew Morton wrote:
> Rik van Riel <riel@redhat.com> wrote:
> 
>>On Fri, 30 Jul 2004, Rik van Riel wrote:
>>
>> > I have run a very unscientific benchmark on my system to test
>> > the effectiveness of the patch, timing how a 230MB two-process
>> > qsbench run takes, with and without the token thrashing
>> > protection present.
>> > 
>> > normal 2.6.8-rc2:	6m45s
>> > 2.6.8-rc2 + token:	4m24s
>>
>> OK, I've now also ran day-long kernel compilate tests,
>> 3 times each with make -j 10, 20, 30, 40, 50 and 60 on
>> my dual pIII w/ 384 MB and a 180 MB named in the background.
>>
>> For make -j 10 through make -j 50 the differences are in
>> the noise, basically giving the same result for each kernel.
>>
>> However, for make -j 60 there's a dramatic difference between
>> a kernel with the token based swapout and a kernel without.
>>
>> normal 2.6.8-rc2:	1h20m runtime / ~26% CPU use average
>> 2.6.8-rc2 + token:	  42m runtime / ~52% CPU use average
> 
> 
> OK.  My test is usually around 50-60% CPU occupancy so we're not gaining in
> the moderate swapping range.

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 would get far more complicated to create a list of tasks trying to 
get the token and refuse to hand it back to the same task until it 
cycled through all the other tasks to prevent this... and I'm not even 
sure that would help since these are all short lived tasks... Any other 
thoughts?

To be honest I dont think this contest result is truly a bad thing...

Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]