[lkml]   [2000]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: More on 2.2.18pre2aa2
On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> On Tue, 12 Sep 2000, Rik van Riel wrote:
> >Uhmmm, isn't the elevator about request /latency/ ?
> Yes, but definitely not absolute "time" latency.
> How do you get a 1msec latency for a read request out of a
> blockdevice that writes 1 request in 2 seconds? See?

Of course, if you set a rediculous latency figure you'll
get rediculously bad performance. However, that doesn't
say /anything/ about if the idea is a good one or not...

Along the same lines, I could redicule the current setup
by running one of the following lines and then pointing
out how bad performance would be.

# elvtune -r 10000000 -w 10000000 /dev/hda
# elvtune -r 1 -w 1 /dev/hda

> That was one of the first issues I was thinking about when I
> started playing with the elevator. (and yes, some of my early
> patches was setting a per-request timestamp using jiffies)
> Note: I understand you can do in function of time something that
> works ok for a normal 10/20Mbyte/sec harddisk, but since the
> elevator is used every time you write to any blockdevice out
> there, you also have to take into account things like ZIP drives
> and whatever other slow device that does less than 1Mbyte/sec
> I/O or even slower (as well as faster devices). A zip drive is
> slow writing, but that doesn't mean it isn't even slower while
> seeking.

We can already set different figures for different drives.
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?


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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:4.041 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site