cvs commit: src/sys/amd64/amd64 identcpu.c mp_machdep.c src/sys/amd64/include smp.h src/sys/i386/i386 identcpu.c mp_machdep.c src/sys/i386/include smp.h src/sys/ia64/ia64 mp_machdep.c src/sys/kern sched_ule.c subr_smp.c ...

[Robert Watson]

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.

Robert N M Watson
Computer Laboratory
University of Cambridge