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

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

KAMEZAWA Hiroyuki wrote:
> On Sat, 17 Jun 2006 13:46:30 +1000
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>
> > > 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.
>
> But it seems the kernel does what users doesn't want.

But they have to tell it to unplug the CPU, don't they? So if they ask
to unplug it but don't want it to unplug, then the kernel can only do
so much.

Or do we automatically unplug in response to some exceptions nowadays?
In that case, it might be better to have a sysctl that can cause it to
do some other behaviour than unplug.

> threads which is tightly coupled to some cpu has some important meanings for
> the userk.
> If the apps are sophisticated as you say, cpus_allowed containes other cpus
> before hotplug.

Yes, then they'll be able to be migrated without changing their cpumask.
So what's the problem?

> As SIGSTOP/KILL patch I posted, the apps shouldn't do unexpected
> work, I think.

I don't quite understand you here... the kernel doesn't need to enforce
anything but a dumb fallback policy where userspace is otherwise capable
of handling it themselves.

--
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/