[lkml]   [2006]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RT task scheduling
    On Fri, Apr 07, 2006 at 11:19:46AM +0200, Ingo Molnar wrote:
    > -ENOPARSE. CPU binding brings with itself obvious disadvantages that
    > some applications are not ready to pay. CPU binding restricts the
    > scheduler from achieving best resource utilization. That may be fine for
    > some applications, but is not good enough for a good number of
    > applications. So in no way can any 'CPU binding mechanism' (which
    > already exists in multiple forms) replace the need and desire for a
    > globally scheduled class of RT tasks.

    You're discussing a different problem than what I'm talking about. Some
    of it probably is terminology, some it is actually multipule problems
    that need to be seperated out and discussed individually. I'm open for
    any help on this matter to communicate my view on this topic.

    I'm talking about two scenarios, (1) a high performance strict RT usage
    of SCHED_FIFO and friends verses (2) a kernel that might have a more
    general purpose orientation that would be looser about rebalancing,
    permitting some RT task of lower priority to run above a higher priority
    for performance sake, what ever...

    > > [...] the key here is "robust". [...]
    > -ENOPARSE. CPU binding is CPU binding. Could you outline an example of a
    > "non-robust" CPU binding solution?

    We're having a terminology problem here... let's pull back a bit.

    Any solution that depends on a general purpose algorithm, heuristic or
    any of thing of that nature, that means any kind of load rebalancing,
    may interfere with RT app of type (1).

    RT applications tend to want explicit control over the scheduling of
    the system with as little interference from the kernel as possible. The
    general purpose policies (RT rebalancing) of the Linux kernel can impede
    RT apps from getting at CPU time more directly. If you have a SCHED_FIFO
    task, it's by default globally rebalanced, right ? Well, the run queue
    search and IPI is going to add to the maximum deterministic response time
    of that thread.

    How do you avoid that ? Well, give the RT app designer the decision to
    hot wire a thread to a CPU so that the rebalancing logic never gets
    triggered. That'll improve latency and the expense of rebalancing. This
    is up to the discretion of the RT app designer and that person is best
    suited to decide where and when that RT thread will run. Current Linux
    kernel policies are sufficient to meet at least part of this requirement
    fairly well. This does not address the general case (2) and is a
    different problem.

    Here I've though of it in terms of letting a per CPU binding suggest
    to the scheduler what kind of rebalancing policy I want verses letting
    a run class determine it. In my opinion, creation of SCHED_FIFO_GLOBAL
    is unneeded because of it. What I meant by "robust" was that folks
    should consider "fully" if binding address the solution or not before
    introducing a new run category. I'm asking "does this address the
    problem entirely ?" if not, *then* consider a new run category only after
    this fails. That's what I'm saying.

    As a side note, consider extended this notion of thread binding so that
    it excludes any other thread from running on a CPU that might make the
    cache cold for that bounded thread. That'll give maximum latency
    performance (sub-microsecond). That's more thinking in terms of CPU

    Does this help with the communication ?


    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: 2006-04-07 12:42    [W:0.023 / U:41.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site