Re: RFC: THE OFFLINE SCHEDULER

[Sven-Thorsten Dietrich]

On Tue, 2009-08-25 at 13:22 -0600, Chris Friesen wrote:
> On 08/25/2009 01:08 PM, Peter Zijlstra wrote:
> 
> > Christoph, stop being silly, this offline scheduler thing won't happen,
> > full stop.
> > 
> > Its not a maintainable solution, it doesn't integrate with existing
> > kernel infrastructure, and its plain ugly.
> > 
> > If you want something work within Linux, don't build kernels in kernels
> > or other such ugly hacks.
> 
> Is it the whole concept of isolating one or more cpus from all normal
> kernel tasks that you don't like, or just this particular implementation?
> 
> I ask because I know of at least one project that would have used this
> capability had it been available.  As it stands they have to live with
> the usual kernel threads running on the cpu that they're trying to
> dedicate to their app.
> 

Its already possible to *almost* vacate a CPU except for a handful of
kernel threads.

There are various hacks being distributed which also offload / suppress
timer and rcu activity from specific CPUs.

Everything I have looked at has been hackish and racy, and no one using
this is pusing any of it upstream.

OFFLINING solves the problem in a minimalist way, and only for tasks
with very limited interaction with the Kernel.

In contrast however, almost all tasks with such limited Kernel
interaction should be able to do fine under PREEMPT_RT after some cpuset
work.

For those which absolutely cannot handle a handful of kernel threads
sharing the CPU, the only option today is one or another form of
hackery, and amongst those options, this would seem attractive by its
mere simplicity.

But complete CPU isolation for user-space tasks still eludes.

Sven


> Chris
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/