Re: RT task scheduling

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

On Sat, Apr 08, 2006 at 10:03:49AM +0200, Ingo Molnar wrote:
> * Bill Huey <billh@gnuppy.monkey.org> wrote:
> > As far as CPU binding goes, I'm wanting a method of getting around the 
> > latency of the rt overload logic in certain cases at the expense of 
> > rebalancing. That's what I ment by it.
> 
> yeah, that certainly makes sense, and it's one reason why i'm thinking 
> about the separate SCHED_FIFO_GLOBAL policy for 'globally scheduled' RT 
> tasks, while still keeping the current lightweight non-global RT 
> scheduling. Global scheduling either means a global lock, or as in the 
> -rt implementation means a "global IPI", but there's always a nontrivial 
> "global" cost involved.

This is an extremely tricky problem which is why I lean toward manual
techniques to resolve the issue. All automatic policies seem to fail for
one reason or another. Significant thought needs to be put to this
problem and you might not be able to effective address all parts of it.

It goes far beyond the conventions of SCHED_FIFO itself and really
forces one to think about what "priority" really is in the context of
the -rt patch, whether the priority range needs to be extended to a much
larger range (0-512 or larger) and other issues regarding that. I see
-rt SCHED_FIFO as a basic building block for other policies (done by
researchers) that can be faked in userspace (like scheduler activations),
but policies vary greatly given a typical load characteritic or demands
of a -rt app. No single policy can fullfill those needs and it's still
largely a research topic in many areas. Rebalancing in allocation
schedulers is still voodoo in SMP environments for example.

Please take this into consideration when thinking about SCHED_FIFO_GLOBAL
and related topics.

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/