From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 23 10:32:32 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94963106566B; Thu, 23 Sep 2010 10:32:32 +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 6E2F48FC0C; Thu, 23 Sep 2010 10:32:32 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id EFBFB46B5C; Thu, 23 Sep 2010 06:32:31 -0400 (EDT) Date: Thu, 23 Sep 2010 11:32:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <4C9A6CB8.3010400@sippysoft.com> Message-ID: References: <4C99DC48.1020208@FreeBSD.org> <201009220937.13155.jhb@freebsd.org> <4C9A6CB8.3010400@sippysoft.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Hackers , Jeff Roberson , freebsd-current@FreeBSD.ORG, "current@freebsd.org" , John Baldwin Subject: Re: Bumping MAXCPU on amd64? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 10:32:32 -0000 On Wed, 22 Sep 2010, Maxim Sobolev wrote: > On 9/22/2010 6:37 AM, John Baldwin wrote: >> Unfortunately this can't be MFC'd to 7 as it would destroy the ABI for >> existing klds. > > Ah, ok, sorry, I did only check RELENG_7. Can we make it a kernel option > then? In principle, yes, but MAXCPU is used to size various kernel data structures inspected by userspace crash post-mortem tools, etc. I've done a bit of work to teach some of those tools (in particular, vmstat -z and vmstat -m) to extract the version of maxcpu compiled into the kernel instead just relying on the version of MAXCPU present when the command line tool was compiled. However, I think a better long-term approach here is to generally eliminate sizing based on MAXCPU and instead size based on the number of CPUs present. Certain kernel subsystems already do this (UMA, netisr, ...) but others don't (malloc(9), ...). Additional hands on this project would probably help :-). As John mentioned, the other issue is the use of fixed-width types instead of variable-length CPU bitmasks to name cores for IPIs, etc. There are people actively working on this, but it's a non-trivial project as kernel code likes to do things like cpumask & othermask. My expectation is that this problem will be solved in 9.0 but I don't see any obvious MFC paths for 8.x due to KBI issues. It could be that this forces our hand in terms of breaking the KBI at some point in the 8.x series, unclear... Robert