On Tue, 11 Apr 2000, Andi Kleen wrote:
>Still it seems get_request() walks a lot of the 256 element request
>array. I could imagine that that will take some time, especially
>when you have many wakeups in 2.2 (in 2.3 wait_for_request is a
>a wake-one waitqueue so it should work better there, 2.2 probably
>has a thundering herd)
get_request() isn't related to the elevator but it's another path that a
worse-case O(N) complexity. You won't be able to see the get_request()
time in the profiling too though.
You can set the request queue back to 128 elements if you want it's fine
for me if you believe 256 is too much. However during dbench benchmarking
on IDE and PII using 256 queue instead of 128 I/O queue I got 2mbyte/sec
improvement, that's why I enlarged it. The other reason I changed it is
that it's shared between all devices (and that's shouldn't be the case).
If you have only one disk then 128 is going to be fine, but for example as
in my case where I was striping using LVM over multiple disks I want a 128
queue for each disk. Also since the new elevator runs in O(1) in the
common case the size of the queue doesn't hurt, as it instead was hurtign
all the time in 2.2.x.
Anyway I don't think that's the cause of the trouble otherwise _everybody_
would have noticed the slowdown all the time (me included in first place
during benchmarking :).
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 : Sat Apr 15 2000 - 21:00:15 EST