Messages in this thread | | | Date | Thu, 26 Jun 2003 19:10:40 -0400 | From | Timothy Miller <> | Subject | Re: O(1) scheduler & interactivity improvements |
| |
Helge Hafting wrote:
> How about _removing_ the io-wait bonus for waiting on pipes then? > If you wait for disk io, someone else gets to use > the cpu for their work. So you get a boost for > giving up your share of time, waiting > for that slow device. > > But if you wait for a pipe, you wait for some other > cpu hog to do the first part of _your_ work. > I.e. nobody else benefitted from your waiting, > so you don't get any boost either. > > This solves the problem of someone artifically > dividing up a job, using token passing > to get unfair priority. > > > This can be fine-tuned a bit: We may want the pipe-waiter > to get a _little_ bonus at times, but that has to be > subtracted from whatever bonus the process at the > other end of the pipe has. I.e. no new bonus > created, just shift some the existing bonus around. > The "other end" may, after all, have gained legitimate > bonus from waiting on the disk/network/paging/os, and passing > some of that on to "clients" might make sense. >
In other words:
Don't give pipe-waiting any kind of boost or penalty, but do balance the interactivity points between entities at each end of the pipe.
So, if you're waiting on a pipe, but the other end is a CPU hog, then since you don't get a boost (pipe wait), you don't give a boost to the CPU hog, but since he's a CPU hog, he DOES share negative points with you, lowering your priority.
Conversely, if a process is waiting on real I/O (disk, user input, etc.), then it gets an interactivity boost that it can share with other processes it's connected to via pipe.
Since most X clients only do pipe waiting on the server, then it's the X server that gets the interactivity boost by waiting on user input, which it can share with clients.
And since there is no effect from pipe wait, you can still judge a process as interactive or not based on what it does when it's NOT waiting on a pipe -- if it becomes a CPU hog THEN, you deduct points, etc.
Here's an interesting question: Would you often have a situation where a process at one end of a pipe is a CPU hog, and the process at the other end is interactive? Is that a problem?
If you're always adding or subtracting points, that situation could be less than optimal, but you'll never get to the point where the interactive process is believed to be a cpu hog or vice versa. The points each process would be assessed at a faster rate than the sharing between processes.
Do you want to always share points, or do you share only when something wakes up from a pipe wait?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |