Re: [PATCH] [request for inclusion] Realtime LSM

Con Kolivas
2005-01-14T04:01:43Z

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]