2.5.68 and 2.5.68-mm2
Quoted 5 lines
Quoted 3 lines
The autoconf-2.53 make/make check is a fork test. 2.5.68
is about 13% faster here.I wonder why. Which fs was it?
That was on ext2. There isn't much i/o on autoconf "make check". It's a lot of small perl scripts, m4 and gcc on tiny files.
Quoted 4 lines
Quoted 1 line
On the AIM7 database test, -mm2 was about 18% faster and
iirc, AIM7 is dominated by lots of
O_SYNCwrites. I'd have expected the anticipatory scheduler to do worse. Odd. Which fs was it?
That was ext2 too.
Quoted 5 lines
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.
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%
Signature · 2 lines
Randy Hron http://home.earthlink.net/~rwhron/kernel/bigbox.html
Quoted 9 lines · [email protected] wrote:
Quoted 6 lines
Quoted 2 lines
On the AIM7 database test, -mm2 was about 18% faster and
iirc, AIM7 is dominated by lots of
O_SYNCwrites. 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.
Quoted 9 lines
Quoted 9 lines
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.
Quoted 10 lines
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?
Quoted 8 lines
Sequential Reads ext2
NumKernel 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.
Quoted 7 lines · Nick Piggin
Quoted 3 lines · [email protected] wrote:
Quoted 3 lines
The benchmark is hitting a pathologoical case. Yeah, it's a problem, but it's not as bad as tiobench indicates.
Quoted 8 lines
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.
Are you using TCQ by any chance? If so, what do the results look like with TCQ off?