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 ...

[Jeff Roberson]

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
>