Messages in this thread | | | Date | 10 May 2004 21:54:39 +0200 | Date | Mon, 10 May 2004 21:54:39 +0200 | From | Andi Kleen <> | Subject | Re: [ANNOUNCE] [PATCH] Node Hotplug Support |
| |
On Mon, May 10, 2004 at 11:17:22AM +0900, Keiichiro Tokunaga wrote: > As you mentioned, there can be many more things. However, > the examples you showed should be handled by individual hotplug. > For instance, the processes bound to a certain CPU should be > handled by CPU hotplug when node hotplug invokes CPU hotplug. > Also, the device drivers bound to slots should be detached by > IO hotplug. Node hotplug is supposed to take care of a container > device and just invoke individual hotplugs for other devices. > Node hotplug doesn't break any policy of each hotplug (CPU, > memory, IO, etc).
To coordinate all them you need user space infrastructure anyways that knows about all the elements of a node. I don't see why you want a kernel level container too; userspace can do this job already and would be much more flexible.
> > This has the advantage that if there is some reason to > > add CPUs without memory (or memory without CPUs or PCI slots > > without anything) it will just work too. It is not clear > > that your "lump everything mechanism into one" can handle all > > that. Most likely you would need to add lots of special > > cases to it to handle all this. Separate mechanisms can > > do this cleaner. > > Yes. The cases (combination of hardware) would increase. > However, I don't think there would be that many today.
I am mainly thinking about virtualization here for which hotplug of everything makes definitely sense. But the requirements could be very different from what a big iron machine wants.
> Are you saying here that platform-independent and dependent > codes should be separated so that the independent part could > be implemented by any other platform (firmware) in their own > style? If so, I agree and some discussion are necessary :)
Yep.
-Andi - 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/
| |