From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 18:29:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C00911065672; Tue, 28 Sep 2010 18:29:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8F93A8FC0A; Tue, 28 Sep 2010 18:29:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4376C46B65; Tue, 28 Sep 2010 14:29:38 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 729E28A03C; Tue, 28 Sep 2010 14:29:37 -0400 (EDT) From: John Baldwin To: Sean Bruno Date: Tue, 28 Sep 2010 14:29:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <1285601161.7245.7.camel@home-yahoo> <1285692311.2454.11.camel@home-yahoo> In-Reply-To: <1285692311.2454.11.camel@home-yahoo> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201009281429.30747.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 28 Sep 2010 14:29:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "sbruno@freebsd.org" , "freebsd-current@FreeBSD.org" , Robert Watson , Joshua Neal 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: Tue, 28 Sep 2010 18:29:38 -0000 On Tuesday, September 28, 2010 12:45:11 pm Sean Bruno wrote: > On Tue, 2010-09-28 at 02:48 -0500, Robert Watson wrote: > > On Mon, 27 Sep 2010, Joshua Neal wrote: > > > > > I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already > > > asking the kernel for the max number and throwing an error if it doesn't > > > agree: > > > > Yes, it looks like MAXCPU was bumped in the kernel without bumping the limit > > in libmemstat. The bug could be in not having a comment by the definition of > > MAXCPU saying that MEMSTAT_MAXCPU needs to be modified as well. > > > > > I was thinking a more future-proof fix would be to get rid of the static > > > allocations and allocate the library's internal structures based on the > > > value of kern.smp.maxcpus. > > > > Agreed. I'm fairly preoccupied currently, but would be happy to accept > > patches :-). > > > > Robert > > Working on a dynamic version today. I'll spam it over to you for review > later. > > I'm moving the percpu struct definitions outside of struct memory_type, > allocating quantity kern.smp.maxcpus, removing the boundary checks based > on MEMSTAT_MAXCPU and then removing MEMSTAT_MAXCPU all together. If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus. -- John Baldwin