Paul Davis wrote:
>>>its a fine answer, but its the answer to a slightly different
>>>question. if anyone (maybe us audio freaks, maybe someone else) comes
>>>up with a reason to want "The Real SCHED_FIFO", the original question
>>>will have gone unanswered.
>>
>>Ah then  you missed something. You can set the max cpu of SCHED_ISO to 
>>100% and then you have it.
> 
> 
> true, i missed that :) but i also recall you saying you were thinking
> of having no prioritization within SCHED_ISO ... or am i remembering
> wrong? 

Nothing is set in stone.  I wont even look at code until Ingo or Linus 
rules on this. Ingo has expressed interest in SCHED_ISO on a previous 
thread with me.

> also, is it just me, or having to ways to achieve the exact
> same result seems very un-linux-like ... and if they are not exact
> same results, how does a regular user get the SCHED_FIFO ones? is the
> answer just "they don't" ?

To answer your question, the second of my proposals was to not have a 
separate scheduling class at all. To let normal users set SCHED_FIFO and 
SCHED_RR, possibly with all their priorities intact, but for there to be 
limits placed on their usage of these classes. The reason I suggested 
not supporting priorities is that proper real time scheduling would 
entail being able to say "I need x cycles, to complete by y time and I 
can or cannot be preempted". With these QoS requirements, a whole new 
scheduling style (EDF) would need to be implemented. Without actually 
implementing this, if you set a limit of cpu to 70%, all it takes is one 
FIFO process to run long enough at high enough priority and all your 
other soft real time tasks go to SCHED_NORMAL, which is nothing like 
what happens with true RT scheduling. Forcing all soft RT threads to 
round robin at the same priority would make them sort themselves out. 
It's a compromise either way, and in fact this latter way is what OSX 
does and works well in practice as well as theory.

Cheers,
Con