lkml.org 
[lkml]   [2005]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [request for inclusion] Realtime LSM
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.129 / U:68.940 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site