Re: RT task scheduling

[Bill Huey (hui) <billh@gnuppy.monkey.org>]

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/