Re: [RFC][PATCH] avoid cpu hot remove of cpus which have special RT tasks.

[Nick Piggin <nickpiggin@yahoo.com.au>]

Andi Kleen wrote:
> On Friday 16 June 2006 12:26, KAMEZAWA Hiroyuki wrote:
>
> > On 16 Jun 2006 11:14:57 +0200
> > Andi Kleen <ak@suse.de> wrote:
> >
> >
> > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> writes:
> > >
> > > > This is a bit pessimistic. But forecd migration of RT task which is bounded
> > > > to the special cpu will cause unpredictable trouble, I think.
> > >
> > > More trouble than running it on a CPU that is about to fail?
> > > Doubtful.
> >
> > With my patch, RT tasks will continute to run.
>
>
> That's the problem - if the CPU is failing and you have to remove
> it the task will likely corrupt its data or fail in other ways
> if it doesn't allow it.
>
> Better to let RT tasks run a little slower on another CPU.
>
>  
>
> > Assume there are some multi-threaded tasks with SCHED_FIFO.
> > If they uses some kind of synchronization in user land and task is migrated to
> > other cpus, it will cause dead-lock.
>
>
> If its CPU fails much worse things than that will happen.
>
> One way might be to break affinity of all processes in the system on hot unplug
> - then your deadlock would be avoided - but it might be a bit radical.

Agreed. The kernel is just doing some basic fallback behaviour. If you
actually have a critical RT system, you probably need to have much more
sophisticated handling of CPU unplug anyway. So it doesn't make much
sense to complicate the kernel for this.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/