[lkml]   [1999]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] new scheduler

    On Mon, 10 May 1999, Rik van Riel wrote:

    > > you have removed priority recalculation, but priority recalculation has a
    > > goal: not running processes gather priority approaching maximum priority
    > > (40) logarithmically. This is how we 'boost' interactive processes
    > > automatically. Maybe i've misread your patch, but where is this mechanizm
    > > now? (or if it's replaced by something else, how does that work?)
    > The mechanism is in the handling of the p->defer value.
    > If the proces runs out of it's time slice, it gets
    > put away in time according to it's priority. If it
    > sleeps and returns after p->defer has happened, it
    > will get full priority and p->counter will be set
    > to full.
    > Handling of interactive and multimedia tasks will
    > be done because CPU hogs are pushed back in time
    > and interactive and multimedia tasks aren't put
    > back as much.

    you dont seem to understand how the current scheduler works. Tasks are
    started with 'normal' priorities. Things like 'telnet' or other
    interactive processes tend to spend only a fraction of their 'due' CPU
    time. Subsequently they get a priority boost to _well above their original

    If i understand your changed timeslice mechanizm correctly then
    'interactive' processes would have typically 'normal' priority, which is
    then slightly decreasing until it reaches zero. (which btw. might be just
    a bug in your scheduler) But anyway, the more important point is that the
    mechanizm of _boosting_ interactive processes above the priority of
    CPU-hogs does not seem to be present. No, CPU-hogs are not necesserily
    reniced processes ... All in one, you end up having a much worse

    as i said earlier, solely concentrating on removing the recalculation
    factor is i think misguided effort, the logarithmic priority boost
    resulting out of recalculation is a _feature_, implementing it in another
    way (ie. with getting the same benefits) might be possible, but removing
    it without having a substitute is plain wrong.

    just to give you an example, with the current 2.2.8 scheduler, run 4
    CPU-hogs and use some interactive process. The interactive process
    _always_ preempts the CPU hog (after some initial 'learning curve'), even
    if the CPU hog has slightly higher priority than the interactive process.
    This happens the very same way on SMP as well, eg. take 3 RT tasks on a
    4-CPU box and 2 'normal' CPU hogs, interactive processes will _always_
    preempt the CPU hogs on whatever CPU they run. It cannot get any better as
    far as interactivity goes, can it?

    -- mingo

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

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