From owner-cvs-src@FreeBSD.ORG Mon Mar 3 09:25:45 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF0D01065675; Mon, 3 Mar 2008 09:25:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C63648FC20; Mon, 3 Mar 2008 09:25:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0F52246B2C; Mon, 3 Mar 2008 04:25:45 -0500 (EST) Date: Mon, 3 Mar 2008 09:25:44 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <47CBC127.8010403@FreeBSD.org> Message-ID: <20080303092335.E66705@fledge.watson.org> References: <200803020758.m227wgH9040483@repoman.freebsd.org> <47CBC127.8010403@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, Jeff Roberson , src-committers@FreeBSD.org, cvs-all@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-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 09:25:46 -0000 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