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, Ingo Molnar wrote:
> 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.

[snip]

> you dont seem to understand how the current scheduler works.

I do. I think you have overlooked the little defer trick
that's present in wake_up_process()...

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

No. Interactive processes that don't use up their time slice
before jiffies reaches p->defer will get their time slice
fully reinstated in wake_up_process().

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

CPU hogs have their p->defer value always a few time slices
in the future, while interactive tasks have their running
deadline in the present. This means that interactive tasks
are always preferred over CPU hogs. Multimeda apps will have
their priority somewhere in the middle. Well, not really, but
it will be like this on average...

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

Problem is that this _only_ works if the interactive process
doesn't use more than a few jiffies of it's time slice. I guess
that rules out things like Enlightenment and Netscape from
being considered interactive. _That_ is a bug, IMHO.
My scheduler gives a little more leeway before a process is
considered hogging the CPU.

I guess there will be no substitute for trying (which I
will do as soon as I have backported the scheduler changes
from the prepatch to 2.2.7 because the interrupt handling
in 2.2.8 broke on my mainboard again).

cheers,

Rik -- Open Source: you deserve to be in control of your data.
+-------------------------------------------------------------------+
| Le Reseau netwerksystemen BV: http://www.reseau.nl/ |
| Linux Memory Management site: http://humbolt.geo.uu.nl/Linux-MM/ |
| Nederlandse Linux documentatie: http://www.nl.linux.org/ |
+-------------------------------------------------------------------+


-
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    [W:0.060 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site