From owner-cvs-all@FreeBSD.ORG Mon Mar 3 12:29:40 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B44281065672; Mon, 3 Mar 2008 12:29:40 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 671E08FC17; Mon, 3 Mar 2008 12:29:40 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m23CTZWg026305; Mon, 3 Mar 2008 07:29:38 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Mon, 3 Mar 2008 02:31:51 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Robert Watson In-Reply-To: <20080303092335.E66705@fledge.watson.org> Message-ID: <20080303022904.E920@desktop> References: <200803020758.m227wgH9040483@repoman.freebsd.org> <47CBC127.8010403@FreeBSD.org> <20080303092335.E66705@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Maxim Sobolev , Jeff Roberson , src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: 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 ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 12:29:40 -0000 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 >