[lkml]   [2005]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] [request for inclusion] Realtime LSM
    Jack O'Quin wrote:
    > Arjan van de Ven <> writes:
    >>On Thu, Jan 13, 2005 at 04:25:08PM -0500, Lee Revell wrote:
    >>>The basic issue is that the current semantics of SCHED_FIFO seem make
    >>>the deadlock/data corruption due to runaway RT thread issue difficult.
    >>>The obvious solution is a new scheduling class equivalent to SCHED_FIFO
    >>>but with a mechanism for the kernel to demote the offending thread to
    >>>SCHED_OTHER in an emergency.
    >>and this is getting really close to the original "counter proposal" to the
    >>LSM module that was basically "lets make lower nice limit an rlimit, and
    >>have -20 mean "basically FIFO" *if* the task behaves itself".
    > Yes. However, my tests have so far shown a need for "actual FIFO as
    > long as the task behaves itself."

    I should comment on this thread on lkml. After some
    investigation/discussion and testing I came up with a proposal for this
    problem. Since we are a general purpose operating system and not a hard
    rt system (although addon patches are clearly making that a future
    possibility) we need a solution that is satisfactory to a general...

    There are two ways I suggested for this.

    First, (and I am increasingly believing in the second) is to implement a
    new scheduling class for isochronous scheduling. This would be a class
    for unprivileged users, and behave like SCHED_RR (to avoid complications
    of QoS features we dont have infrastrucutre for) at a priority just
    above SCHED_NORMAL, but below all privileged SCHED_RR and SCHED_FIFO.
    Importantly, a soft cpu limit and rate period can be set by default for
    this scheduling class that provides good true SCHED_RR performance, and
    is configurable. Literature suggests that 70% is adequate cpu for good
    real time performance and would be starvation free. I believe setting
    70% with 10% hysteresis (dropping to say 63% on hitting limit) would be
    a good start. Beyond this, however, to satisfy the needs of those with
    more demanding setups, a simple configurable runtime setting to set both
    the cpu% and the rate period could be available to something as simple
    as proc
    where iso_cpu is set to 70, and period to maybe 1 second. The actual
    mode of setting this tunable is not important, and could be in /sys or

    The second option is to not implement a new scheduling class at all, and
    allow unprivileged users to use either SCHED_FIFO or SCHED_RR, but to
    make the cpu constraints described for SCHED_ISO above apply to their
    use of those classes. Supporting priority settings for these could be
    possible, but in my opinion, it would work as a better class if they
    only had one priority level, as for the SCHED_ISO implementation above
    (better than any SCHED_NORMAL, but lower than privileged SCHED_RR/FIFO).

    This latter approach to me seems the least invasive and most user and
    sysadmin friendly method.

    What was amusing to me was that after I suggested the latter option, I
    discovered that was basically what OSX does, however being not a real
    multi-user operating system they had absurd limits for cpu at 90% by
    default. Theory suggests 70% should be a good default limit.

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 14:09    [W:0.058 / U:13.644 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site