lkml.org 
[lkml]   [2004]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] token based thrashing control
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.169 / U:4.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site