[lkml]   [2005]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] [request for inclusion] Realtime LSM
    On Fri, 2005-01-14 at 15:00 +1100, Con Kolivas wrote:
    > 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.

    You may have a chicken and egg problem :) I don't think anybody will
    rule on this unless there is at least a demand for it. For there to
    be a demand for it I think you'd need to come up with a rigorous
    specification, wouldn't you? And then implement it even.

    Unfortunately this is just how kernel development goes if you're brave
    enough to try out new things.

    I'm leaning toward the opinion that the entire problem would be better
    handled purely with the existing RT scheduling classes, and a good way
    to handle the security side of things.

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

    This sort of thing is pretty well specialised enough that it doesn't
    belong in the kernel scheduler, however. Often it can be satisfied by
    userspace managers... but you'd have to be talking about a hard RT
    system anyway, which Linux isn't. - Yahoo! Mobile

    - Check & compose your email via SMS on your Telstra or Vodafone mobile.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:4.071 / U:0.004 seconds]
    ©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site