Messages in this thread Patch in this message | | | Date | Sun, 27 Feb 2000 15:33:43 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [PATCH] proposed scheduler enhancements and fixes |
| |
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/
| |