KAMEZAWA Hiroyuki wrote:
On Sat, 17 Jun 2006 13:46:30 +1000
Nick Piggin <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
