Re: More on 2.2.18pre2aa2

From: Rik van Riel (riel@conectiva.com.br)
Date: Tue Sep 12 2000 - 10:17:20 EST


On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> 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.

*sigh*

People don't use their machine to run `hdparm -t` all day.
They use their machine for different things, and user
perceived latency varies wildly between different loads
users put on the machine...

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

Why do you always come up with impossible examples?
If you had any realistic example I'd be inclined to
believe your argument, but this is just not realistic
enough to be taken seriously ...

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

Not for 10 minutes no, but even with the latency set to 100
and 100 I sometimes get /bad stalls/ in just one or two
processes (while the rest of the system happily runs on).

On the other hand, when I do something different with my
machine, the settings 250 and 500 (or even higher) give
perfectly fine latency...

By applying a /different/ IO load, the same settings with
the current elevator tuning give wildly different results.

What I'd like to see is an elevator where the settings set
by the user have a direct influence in the behaviour observed.

Doing time-based request sorting should give us that behaviour
and a default of say 1/2 second would work fine for all the
hard disks and cdrom drives I've seen in the last 6 years.

Of course you can dream up an imaginary device where it won't
work, but in that case there's always the possibility of tuning
the elevator (like we do right now) ...

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