Re: [BENCHMARK] 2.5.68 and 2.5.68-mm2

Nick Piggin (piggin@cyberone.com.au)
Sat, 26 Apr 2003 12:20:43 +1000


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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/