Messages in this thread |  | | Date | Tue, 12 Sep 2000 12:17:20 -0300 (BRST) | From | Rik van Riel <> | Subject | Re: More on 2.2.18pre2aa2 |
| |
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/
|  |