Re: [SHED] Questions.

[Nick Piggin]

Ian Kumlien wrote:

> [Forgot CC to LKML and Robert Love, sorry ]
>
> On Mon, 2003-09-01 at 17:07, Daniel Phillips wrote:
>
> > On Monday 01 September 2003 01:41, Robert Love wrote:
> >
> > > Priority inversion is bad, but the priority inversion in this case is
> > > intended.  Higher priority tasks cannot starve lower ones.  It is a
> > > classic Unix philosophy that 'all tasks make some forward progress'
> > So if I have 1000 low priority tasks and one high priority task, all CPU 
> > bound, the high priority task gets 0.1% CPU.  This is not the desirable or 
> > expected behaviour.

In my implementation, the high prio guy gets 1.9% CPU and the others get
0.09%. However, in all implementations, the high priority one will be 
allowed
to preempt the any of others, of course.

At this point you can safely abandon the consideration that a user might be
running KDE as well ;)

> > My conclusion is, the strategy of expiring the whole active array before any 
> > expired tasks are allowed to run again is incorrect.  Instead, each active 
> > list should be refreshed from the expired list individually.  This does not 
> > affect the desirable O(1) scheduling property.  To prevent low priority 
> > starvation, the high-to-low scan should be elaborated to skip some runnable, 
> > high priority tasks occasionally in a *controlled* way.
>
> I like this idea.
> You could handle the priority starvation with a "old process" boost.
> (i don't know which would be simpler or if there is something even
> simpler out there)
>
> This would ensure that all processes are run sooner or later. Real
> cpuhogs would run very seldom due to being starved, but run when they
> get the boost. On a loaded system this might be desirable since most
> login tools would be "normal" or "high pri" from the get go.
> (there might be a problem with locks though)
>
> This should also work hand in hand with timeslice changes imho. Aswell
> as process preemption. If we assume that cpu hogs has work that they
> want to get done, let em do it for as long as possible. If something
> "important" happens, it'll be preempted right?

This is really just another variation on the idea of dynamic timeslices.
Mine does it explicitly. This idea and the interactivity idea do it
implicitly (not that thats bad).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/