lkml.org 
[lkml]   [1999]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
priority_.

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
scheduler.

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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site