lkml.org 
[lkml]   [2003]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [SHED] Questions.
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.048 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site