From owner-freebsd-current@FreeBSD.ORG Mon Sep 27 21:21:31 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9A4C106566C; Mon, 27 Sep 2010 21:21:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C00188FC14; Mon, 27 Sep 2010 21:21:31 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6A95846B06; Mon, 27 Sep 2010 17:21:31 -0400 (EDT) Date: Mon, 27 Sep 2010 22:21:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sean Bruno In-Reply-To: <1285604516.7245.16.camel@home-yahoo> Message-ID: References: <1285601161.7245.7.camel@home-yahoo> <4CA0BE08.50408@freebsd.org> <1285604516.7245.16.camel@home-yahoo> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "sbruno@freebsd.org" , "current@freebsd.org" Subject: Re: MAXCPU preparations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 21:21:32 -0000 On Mon, 27 Sep 2010, Sean Bruno wrote: >> wouldn't it be better to do a sysctlbyname() and use the real value for the >> system? libmemstat contains some useful sample code showing how this might be done. > That was my initial thought (as prodded by scottl and peter). > > If it is made dynamic, could this be opening a race condition where the call > to sysctlbyname() returns a count of CPUS that is in turn changed by the > offlining of a CPU? Or am I thinking to much about this? Yes, you are. MAXCPU is a compile-time constant for kernel builds, so (at least a the world is today), that can't happen. I think there's a reasonable argument that MEMSTAT_MAXCPU should be phased out and all internal structures in libmemstat should be dynamically sized. However, core counts aren't growing that fast, and it's quite a bit of work, and probably not worth it just yet. I'm somewhat averse to using MAXCPU in libmemstat, however, because MAXCPU is actually not a constant in the general case: FreeBSD/i386, for example, regularly uses two different values: 1 for !SMP kernels, and 32 for SMP kernels. That's why libmemstat encodes its own value, for better or worse. A reasonable alternative would be to replace 32 with MAXCPU * 2, or if we're feeling particularly optimistic, MAXCPU * 4. Or just another big number, like 256. Robert