From owner-freebsd-current@FreeBSD.ORG Sun Oct 8 16:07:39 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6980A16A403 for ; Sun, 8 Oct 2006 16:07:39 +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 1AE7743D45 for ; Sun, 8 Oct 2006 16:07:39 +0000 (GMT) (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 91E0A46BB1; Sun, 8 Oct 2006 12:07:38 -0400 (EDT) Date: Sun, 8 Oct 2006 17:07:38 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Astrodog In-Reply-To: <2fd864e0610080423q7ba6bdeal656a223e662a5d@mail.gmail.com> Message-ID: <20061008170555.D92182@fledge.watson.org> References: <2fd864e0610080423q7ba6bdeal656a223e662a5d@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: [PATCH] MAXCPU alterable in kernel config - needs testers 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: Sun, 08 Oct 2006 16:07:39 -0000 On Sun, 8 Oct 2006, Astrodog wrote: > With the quad core processors coming out soon, this is going to become more > of an issue.. (Sun T1/2000s aside). This is basically the same patch from a > few months ago, with updated offsets. > > If you don't define MAXCPU in the kernel config, it reverts to old behavior. > It has no logic to keep you from shooting yourself in the foot though.. you > can define options SMP and options MAXCPU 128 on arm. Changing MAXCPU is tricky, because it's not just used by the kernel, it's also used by user applications that use kmem to explore kernel data structures. libmemstat jumps through some rather awkward hopes to deal with data structures sized using MAXCPU. Likewise, for CPU masks things get tricky. We need to address this issue, and need to make sure we do it on a coherent way or we'll start running into a variety of bugs associated with varying something that existing pieces of code think is invariant. Unfortunately, it's not just a question of grepping user space for MAXCPU references, you also have to grep for the data structures that use MAXCPU... Robert N M Watson Computer Laboratory University of Cambridge