[lkml]   [1998]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] scheduler patch, faster still
    Richard, I have never seen you actually describe what the
    real-time limits for your application are, or how the current
    Linux scheduler is causing it to hit that limit. I've noticed
    your results, but I am not seeing everyone duplicate them, nor
    a real explanation of how they are causing you a problem in real

    Where I come from, "real-time" doesn't mean "minimum latency", it
    means "guaranteed response time". True real-time scheduling is
    harder than just reducing scheduling latency in the cases where
    multiple real-time tasks exist on the same machine or when a
    mixture of real-time and non-real-time tasks exist. For example,
    the guaranteeable minimum latency depends a great deal on the
    maximum interrupt processing time. If multiple real-time tasks
    exist, then the possibility exists that one can break the other
    when events come in for both and one task longer to respond and
    yield than the other task's required response time.

    Your notion of "RT performance" as being necessarily improved by
    reducing scheduler latency is much too simplistic. As long as
    your process is scheduled within the necessary amount of time
    after an event, and gets to run long enough to perform the
    processing needed for that event, then it doesn't so much matter
    what the exact scheduling latency is, as long as it's always less
    than that limit.

    If you have a real-time application where response times of
    microseconds are required and these scheduling latencies that you
    (but not other people) are seeing are significant, you probably
    can't run it on normal hardware, let alone as a user process in
    Linux. On a general timesharing system, can you guarantee that a
    hardware operation requiring interrupts or DMA initiated by a
    low-priority process won't stall your real-time task? At best
    you'd have to hook the real-time task up to a hardware interrupt
    of high priority in order to make that level of guaranteed
    response time. Otherwise I can't see how you can get that kind of
    real-time performance in any kind of timesharing environment no
    matter how you hack the OS.

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

     \ /
      Last update: 2005-03-22 13:44    [W:0.021 / U:63.140 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site