On Tue, 12 Sep 2000, Rik van Riel wrote:
>But you don't. Transfer rate is very much dependant on the
>kind of load you're putting on the disk...
Transfer rate means `hdparm -t` in single user mode. Try it and you'll see
you'll get always the same result.
>Throughput really isn't that relevant here. The problems are
Thoughput is relevant. Again, how do you get a 1msec latency out of a
blockdevice that writes 1 request every two seconds?
>With equally horrible results for most machines I've
>seen. For a while I actually thought the bug /must/
>have been somewhere else because I saw processes
>'hanging' for about 10 minutes before making progress
>again ...
As said in my earlier email the current 2.4.x elevator scheduler is
_disabled_. I repeat: you should change include/linux/elevator.h and set
the read and write latency to 250 and 500 respectively. You won't get
latency as good as in test1, but it won't hang for 10 minutes.
I and Jens sent a patch to Linus to reenable that push fixing some other
problem of the blkdev merging reported by Giuliano Pochini, plus wake-one
flow control, plus I fixed the DMA_CHUNK_SIZE thing that was buggy and
it's still buggy in the sparc64 case (I didn't fixed sparc64 in my patch,
the DMA_CHUNK_SIZE should limit the segments to
max(64,SHpnt->sg_tablesize) and not to 64 as now), plus it allowed 512K
sized SCSI commands, plus some other minor thing but it didn't get merged.
>Not really. What about just using something like
>"half a second, but at least 10 requests liberty to
>reorder" ?
I doesn't make sense.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:18 EST