Re: More on 2.2.18pre2aa2

From: Rik van Riel (riel@conectiva.com.br)
Date: Tue Sep 12 2000 - 09:41:05 EST


On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> On Tue, 12 Sep 2000, Rik van Riel wrote:
>
> >We can already set different figures for different drives.
>
> Right.
>
> >Would it really be more than 30 minutes of work to put in
> >a different request # limit for each drive that automatically
> >satisfies the latency specified by the user?
>
> Note that if you know the transfer rate of each of your harddisk

But you don't. Transfer rate is very much dependant on the
kind of load you're putting on the disk...

> you can just almost emulate the "in function of time" behaviour
> by converting from "throughput" and "latency in function of
> time", to "latency in function of bh sized requests". (one
> userspace script could do that automatically for example using
> hdparm to first benchmark the throughput)

Throughput really isn't that relevant here. The problems are
seek time and latency as perceived by the user. Both are
measured in /time/ ...

> The reason I prefer working with "latency in function of bh
> sized requests" in kernel space is that I can just use one
> constant for most of the blockdevices.

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 ...

> Using the same latency setting with the "in function of time
> approch" would be wrong instead (and you should gather some
> hardware info from the device before you are able to decide a
> good constant).

Not really. What about just using something like
"half a second, but at least 10 requests liberty to
reorder" ?

It's simple, should be good enough for the user and
allows for a little bit of reordering even on very
slow devices ...

regards,

Rik

--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/ http://www.surriel.com/

- 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