Re: [BENCHMARK] 2.5.68 and 2.5.68-mm2

From: Nick Piggin <piggin@cyberone.com.au>
To: rwhron@earthlink.net
Cc: akpm@digeo.com, linux-kernel@vger.kernel.org
Subject: Re: [BENCHMARK] 2.5.68 and 2.5.68-mm2
Date: Sat, 26 Apr 2003 12:20:43 +1000	[thread overview]
Message-ID: <3EA9ECFB.5050407@cyberone.com.au> (raw)
In-Reply-To: <20030426015856.GA2286@rushmore>


rwhron@earthlink.net wrote:

>>>On the AIM7 database test, -mm2 was about 18% faster and
>>>
>
>>iirc, AIM7 is dominated by lots of O_SYNC writes.  I'd have expected the
>>anticipatory scheduler to do worse.  Odd.  Which fs was it?
>>
>
>That was ext2 too.
>
Well thats nice for a change. The set of workloads which do worse
on AS are obviously more specific than sync writes. I think
multiple threads reading and writing to a similar area of the
disk. Not sure though.

>
>
>>tiobench will create a bunch of processes, each growing a large file, all
>>in the same directory.  
>>
>
>>The benchmark is hitting a pathologoical case.  Yeah, it's a problem, but
>>it's not as bad as tiobench indicates.
>>
Its interesting that deadline does so much better for this case
though. I wonder if any other differences in mm could cause it?
A run with deadline on mm would be nice to see. IIRC my tests
showed AS doing as well or better than deadline in smp tiobench.
The bad random read performance is a problem too, because the
fragmentation should only add to the randomness.
I'll have to investigate this further.

>
>Oracle doing reads/writes to preallocated, contiguous files is more 
>important than tiobench.  Oracle datafiles are typically created
>sequentially, which wouldn't exercise the pathology.
>
>I pay more attention the OSDL-DBT-3 and "Winmark I" numbers than 
>the i/o stuff I run.  (I look at my numbers more, but care about
>theirs more).
>
>What about the behavior where CPU utilization goes down as thread
>count goes up?  Is she just i/o bound?
>
>Sequential Reads ext2
>	       Num                 
>Kernel         Thr   Rate   (CPU%)  
>----------     ---   -----  ------
>2.5.68           8   36.65  18.04%  
>2.5.68-mm2       8   23.96  11.15%  
>
>2.5.68         256   34.10  16.88%  
>2.5.68-mm2     256   18.84   8.96%  
>
Well its doing less IO. Look at CPU efficiency which appears to
be rate / cpu. It is steady - an amount of IO will cost an
amount of CPU.