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

    \
     
     \ /
      Last update: 2005-03-22 13:36    [W:0.031 / U:0.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site