Hi Dave,
Thanks for putting it better than I was. That really is my main
thesis, it was becoming clear that I was not getting that across
effectively.
I also think that until this can be effectively attacked then the
ability of Linux to scale under large I/O demands is going to be
limited.
Cheers,
Bruce.
---------- Original Message ----------
From: David Hinds <dhinds@valinux.com>
Date: Fri, 11 Feb 2000 15:39:05 -0800
Subject: Re: elevator-starvation-4 (2.2.14 && 2.3.42)
> Do you want your interactive program to wait 14 GB because
> some program in the background is in need of reading or
> writing 14 GB of data?
Tweaking the elevator algorithm does not really help you much. It
will let you eeek out a little bit of bandwidth for other things in
the face of the "cat /dev/zero > x" situation, but aside from a few
(possibly important) special cases, it is wrong to try to implement a
user-level fairness policy (which is what you are really asking for)
based on just the information available in the request queue.
I think this is Bruce's real point. It may be that it is still useful
to tweak the elevator algorithm because this particular trigger is not
uncommon and the fix is easy, and because a comprehensive fix is hard.
But Bruce is right that a real fix requires attacking the problem at a
higher level than just reordering requests in the queue.
(as long as a process can generate outstanding requests faster than
they can be serviced, a process can quickly grow the request queue to
be arbitrarily long, and at that point, it doesn't matter how fairly
it is serviced: the bandwidth available to other processes can be made
arbitrarily small)
- -- Dave Hinds
Please read the FAQ at http://www.tux.org/lkml/
--
--
------------------------------------------------------------------------
Bruce Thompson | "Pinky! Are you pondering what I'm
Palm Computing, Inc. | pondering?"
| "Uh, I think so Brain, but where will
| we find a duck and a hose at this
bruce@otherother.com | hour?"
My opinions are strictly my own.
PGP Fingerprint: 8F48 7FEF EE22 14FB 1F2E 3BF2 0D40 9628 53E8 72EB
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:23 EST