On 17 Sep 2000, Peter Osterlund wrote:
> Andrea Arcangeli <andrea@suse.de> writes:
>
> > While the queue is plugged or with things like SCSI your logic
> > change won't work because in such case if your request is lower the
> > lowest in the queue, you can put it at the head of the queue and you
> > have no way to know where your "tmp1" was placed so you can't make
> > any assumption (that's why the current code makes sense).
>
> I still don't think the current code makes sense.
[snip examples]
Indeed, it's obvious that your code will give better
results (and it's more readable too). I like it...
> The new patch is also not unfair to requests near the end of the
> disk. The current kernel code can starve those requests a very
> long time if the request queue never becomes empty.
This is a very very big problem, which definately needs
to be addressed ASAP. I've witnessed this starvation happen
a couple of times and it's a really big problem...
> The only disadvantage I can see is that the new patch doesn't
> handle consecutive insertions in O(1) time, but then again, the
> pre-latency elevator code didn't do that either. Is this really
> important? How long can the request queue be? Apparently we gain
> more by avoiding disk seeks than we lose by wasting some CPU
> cycles during request insertion.
Well DUH. ;)
A disk seek takes ~10 milliseconds on a modern drive,
that's about an /eternity/ as far as the CPU is concerned.
Anyone who thinks saving on CPU time is worth it for
something as critical to disk seeks as the elevator code
should be locked up inside a microVAX ;)
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 : Sat Sep 23 2000 - 21:00:15 EST