On Sun, 27 Feb 2000, Ingo Molnar wrote:
>On a 4-way Xeon 'dbench 8' should produce the workload that stresses
Where can I find dbench? It would be interesting for me to see at least
the kind of workload that it generates on the machine. Also which
blockdevice are you using?
>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
I planned to implement 4 cases (instead of 2 as now) as suggested by
Linus. That seems necessary in practice and I'll verify this very soon.
>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
Just another idea: another thing that may make a difference are the smp
scheduler changes I did in the latest 2.3.4x. You can try to backout this
patch:
ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.3/2.3.42/SMP-scheduler-1.gz
I only had good feedback about that smp changes and they looks ok, so I
don't think they are the problem. I also have an incremental smp patch
against 2.3.48pre4, btw:
ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.3/2.3.47/smp-sched-1.gz
More probably it's the new elevator that is not yet well tuned so in the
meantime you can try out this patch against 2.3.48pre4 and check if
performance returns high:
--- 2.3.48pre4/include/linux/blkdev.h Sun Feb 27 04:01:30 2000
+++ /tmp/blkdev.h Sun Feb 27 15:21:29 2000
@@ -164,7 +164,7 @@
#define MAX_READAHEAD 31
#define MIN_READAHEAD 3
-#define ELEVATOR_DEFAULTS ((elevator_t) { 0, NR_REQUEST>>1, NR_REQUEST<<5, 4, 0, })
+#define ELEVATOR_DEFAULTS ((elevator_t) { 0, NR_REQUEST<<2, NR_REQUEST<<5, NR_REQUEST, 0, })
#define blkdev_entry_to_request(entry) list_entry((entry), struct request, queue)
#define blkdev_entry_next_request(entry) blkdev_entry_to_request((entry)->next)
If performance returns high you can keep safely to use the above patch in
the meantime we'll get it right.
Andrea
-
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