[lkml]   [2003]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] O13int for interactivity

    Nick Piggin wrote:

    > If cc1 is doing a lot of waiting on IO, I fail to see how it should be
    > called a CPU hog. OK I'll stop being difficult! I understand the problem
    > is that its behaviour suddenly changes from IO bound to CPU hog, right?
    > Then it seems like the scheduler's problem is that it doesn't adapt
    > quickly enough to this change.
    > What you are doing is restricting some range so it can adapt more quickly
    > right? So you still have the problem in the cases where you are not
    > restricting this range.

    For this, I reiterate my suggestion to intentionally over-shoot the
    mark. If you do it right, a process will run an inappropriate length of
    time only every other time slice until the oscillation dies down.

    Let me give you an example. Let's say you have a process which is being
    interactive, and then suddenly becomes a CPU hog.

    In the case as it is (assumptions here), what happens is that the
    priority is reduced by some amount until it reaches a level appropriate
    for the new behavior.

    I get the impression that lower numbers mean higher priority, so here goes:

    - The process starts out with a priority of 10 (this may mean something
    that I don't know about... just follow along).
    - It becomes a CPU hog sufficient to make it NEED to be at a priority of 30.
    - Over some number of time slices, the priority is changed something
    like this: 10, 20, 25, 27, 28, 29, 30.

    Here's my alternative suggestion -- if 10 is pure interactive and 30 is
    CPU hog, and you see some change in behavior, before, you would go half
    way. Now, instead, go one-and-a-half way.
    - Over some number of time slices, the priority is changed like this:
    10, 40, 25, 32, 27, 31, 28, 30

    Let's say that you only get one time slice which is CPU hog, but others
    are not, for the first case, you'd get something like this:
    10, 20, 15, 12, 11, 10

    For the second case, you'd get this:
    10, 40, -5, 17, 7, 11, 10

    Something like that. So instead of getting tricked and having to
    return, it over shoots but makes up for it the next time the process is run.

    This is a very incomplete thought and may be pure garbage, so please
    forgive me if I'm being an idiot. :)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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