On Mon, 3 Mar 2008, Robert Watson wrote:
On Mon, 3 Mar 2008, Maxim Sobolev wrote:
Cool! I am just curious if the new topology code is flexible enough to
support cores that come and go on the fly? This could be useful in several
scenarios, such as for example when running under multi-core aware
hypervisor (e.g. Niagara), in the cases when pro-active power manager shuts
down some cores to conserve power, in server applications when one of CPUs
either has fried or has been unplugged, etc.
We have quite a bit of kernel code that expects CPUs never come and go; I've
been hoping to interest people in having a devsummit session on CPU
hotplugging for a couple of years now. :-) I don't see physical hotplugging
as all that motivating currently, by hypervisor reallocation of CPUs *is*
immediately motivating. You'll find assumptions of fixed CPUs all over our
kernel -- schedulers, memory allocators, timer management, etc. A mature
model for starting and stopping CPUs and allowing kernel subsystems to
register with event handlers in order to start/stop their own services is
necessary. Similarly, providing a way for user applications that care about
CPU placement to hook into the event stream and respond appropriately is
important.
Just to add a little bit more about cpu migration. Presently cpuset
enforces a hard limit on the cpus that a thread can run on. Also,
attempts to restrict the cpu set that would leave a thread without a
processor to run on fail. In the future I intend to add a force mode that
would return the thread to the default set.
These features can be used to migrate all of the threads in the system off
of certain processors. However, there is still a lot of state, as robert
has mentioned, that would have to be reclaimed.
I think long term what we need is a per-cpu init chain to take care of
these subsystems. I wasn't aware that we ran well enough within any
virtualization environment that this might be considered a useful feature.
Can anyone comment on that?
Thanks,
Jeff
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
