Messages in this thread | | | Date | Fri, 11 Feb 2000 15:39:05 -0800 | From | David Hinds <> | 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
- 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/
| |