Messages in this thread | | | Date | Sun, 27 Feb 2000 14:41:33 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: [PATCH] proposed scheduler enhancements and fixes |
| |
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/
| |