Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Giuliano Pochini]

> 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/