Messages in this thread | | | Date | Fri, 7 Apr 2006 03:39:26 -0700 | Subject | Re: RT task scheduling | From | Bill Huey (hui) <> |
| |
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 binding.
Does this help with the communication ?
bill
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |