Re: RT task scheduling

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

On Thu, Apr 06, 2006 at 09:37:53AM +0200, Ingo Molnar wrote:
> do "global" decisions for what RT tasks to run on which CPU. To put even 
> less overhead on the mainstream kernel, i plan to introduce a new 
> SCHED_FIFO_GLOBAL scheduling policy to trigger this behavior. [it doesnt 
> make much sense to extend SCHED_RR in that direction.]

Ingo,

You should consider for a moment to allow for the binding of a thread to
a CPU to determine the behavior of a SCHED_FIFO class task instead of 
creating a new run category. Trying to anticipate the behavior of a
thread via a kernel semantic removes control from the applications using
them and into the kernel which is often incorrect about those assumption.

Con might have comments the matter that might be useful.

The current IPI method you use to balance RT is fine. I don't think it
should be changed for the general SCHED_FIFO case, but I do think that
binding a thread to a certain CPU, or set of CPUs, would simplify various
control cases, where the default case is to rebalance immediately via an
IPI. Having a specific case only running on a specific CPU or CPU set
should be the only mechanism to either "isolate" a CPU or create a
condition that's more deterministic than a global policy that -rt is
doing now.
 
This is consistent to how I would use it in an app and wouldn't create
clutter in scheduling code that is already under minor refactoring.

> my gut feeling is that it would be wrong to integrate this feature into 
> smpnice: SCHED_FIFO is about determinism, and smpnice is a fundamentally 
> statistical approach. Also, smpnice doesnt have to try as hard to pick 
> the right task as rt_overload does, so there would be constant 
> 'friction' between "overhead" optimizations (dont be over-eager) and 
> "latency" optimizations (dont be _under_-eager). So i'm quite sure we 
> want this feature separate. [nevertheless i'd happy to be proven wrong 
> via some good and working smpnice based solution]

Please consider the ideas I've mentioned above and research how other
RTOSes deal with these critical issues.

Thanks

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/