Re: [SHED] Questions.

[Nick Piggin <piggin@cyberone.com.au>]

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