lkml.org 
[lkml]   [2000]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.037 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site