Messages in this thread | | | Date | Tue, 3 Feb 2004 04:26:33 -0500 (EST) | From | Ingo Molnar <> | Subject | Re: [PATCH 3/4] 2.6.2-rc2-mm2 CPU Hotplug: The Core |
| |
On Tue, 3 Feb 2004, Rusty Russell wrote:
> Wrong migration thread. The migration thread on CPU 1 has been asked to > push into CPU 0, which is now going down.
you are right - this one place would have to be aware of CPUs going away.
> Now I've slept on the "do it atomically" idea, I think it's a good one. > I've even worked out how to maintain the "last thread on CPU is the idle > thread", although I'd need to test in code.
good!
> In practice, any app which wants to scale with # CPUs needs to know when > CPUs are coming up, as well as going down. Ditto memory, etc. This > means they need to listen for the hotplug event (DBUS anyone?), or we > introduce a SIGRECONF (default ignored). But AFAICT, introducing a new > signal isn't possible (at least on x86) without breaking glibc.
you can introduce a variable RT signal for this purpose no problem - and one would want to have a queued signal for this anyway. Ie. by default the notification is disabled, but a new syscall sets up the process to be notified of CPU up/down events, on a signal # picked by the app. But this this indeed is dbus domain ...
Ingo - 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/
| |