> The current HUGE queue size is probably another reason for
> the very bad latencies we sometimes see...
Yes, but if the queue is short processes are likely to remain
blocked in D state for more time and the chances to merge rq
are smaller.
IMHO we should add a way to give priority to rqs from live
tasks. i.e. a "cp" usually puts stuff on the queue and then
exits. There's no need to service that i/o immediately.
> > I don't think you should allow merges. If one process is doing a big
> > IO operation on a big file it would still get _all_ capacity, right?
>
> Only if you were to allow unlimited merges ;)
>
> I guess a 'decent' maximum size for one request would
> be somewhere around 256kB, since this is the amount of
> data a drive can read in the time of one disk seek...
Today's HDs transfer rates of 10+MB/s are not uncommon. 256KB is a bit
too small IMHO. SCSI discs that don't support TQ (e.g. quantum) get a
performance hit.
Bye.
-
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 : Sat Sep 23 2000 - 21:00:13 EST