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-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
