On Sat, 26 Feb 2000, Linus Torvalds wrote:
> >This was MP (4 Xeon @500MHz). As another data point, on the same machine,
> >dbench 32 has a throughput of about 42MB/s with 2.3.40. With stock 2.3.47
> >it's just under 7MB/s and the CPUs have a much lower utilization (27% out of
> >the 4 CPUs versus 100+% with 2.3.40).
>
> Ingo, have you taken a look at this? It looks scary..
>
> The dbench thing in particular is unhappy. It may be because Andrea
> fixed the SMP filesystem corruption bug (look for added "lock_kernel()"
> calls in 2.3.47 or 46 - we didn't protect the low-level FS code well
> enough, apparently - which gives really nice scaling but sadly wrong
> results ;/ )
the best dbench number with those buggy kernels i've seen on 8-way Xeons
was around NB=300MB/sec. With 2.3.48 i can see NBN=275MB/sec, which is
still pretty good (9% slower), given all the additional VFS overhead we
had to add to be correct. (and we have spinlock and waitqueue debugging
on, turning that off gives a few MB/sec as well. The 300MB/sec was done
with no spinlock debugging.) So i can see nothing dramatic in the 'cached
dbench' case.
On a 4-way Xeon 'dbench 8' should produce the workload that stresses
filesystem scalability in the best way. On an 8-way Xeon it's 'dbench 13'
that gives the best numbers.
i've never really checked the 'IO contended' numbers (because IO
contention behavior depends so much on the actual disk hardware and IO
queueing and buffer-cache details), and i suspect the above bad result
might just be an effect of bad VM balancing and too much IO/swapping
activities? (the fact that CPU utilization is low might be another sign of
this) 'dbench 32' on a non-PAE kernel has a working set that just runs out
of the ~900MB kernel-direct memory area we have. Once dbench goes into 'IO
contended' mode, it heavily relies on the IO layer and the other
scalability factors become much less relevant.
A possibly related thing: i've noticed a strange slowdown in certain IO
workloads (like 'sync' or /sbin/lilo latency) since around 2.3.45 or 46 or
47. I do not want to 'blame' the (new and wonderful) ll_rw_blk.c
latency-adaptive IO scheduler, but thats the only change i can think of
that could have such a drastic effect. I wanted to mention this but held
off with this until that code stabilizes - but now it appears to be pretty
bugless and tested, but the slowdown remained. I suspect it's somehow
write ordering or write latency related, reads do not appear to be slower.
(in fact it feels faster) Write latency and write clustering is a thing
that influences dbench IO-contended performance alot.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:17 EST