From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 19:07:53 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 89E41106566C; Tue, 28 Sep 2010 19:07:53 +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 58EF78FC0C; Tue, 28 Sep 2010 19:07:53 +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 0623146B9B; Tue, 28 Sep 2010 15:07:53 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 308638A04F; Tue, 28 Sep 2010 15:07:52 -0400 (EDT) From: John Baldwin To: sbruno@freebsd.org Date: Tue, 28 Sep 2010 15:06:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <1285601161.7245.7.camel@home-yahoo> <201009281429.30747.jhb@freebsd.org> <1285699244.2454.63.camel@home-yahoo> In-Reply-To: <1285699244.2454.63.camel@home-yahoo> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201009281506.35960.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 28 Sep 2010 15:07:52 -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: "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 19:07:53 -0000 On Tuesday, September 28, 2010 2:40:44 pm Sean Bruno wrote: > On Tue, 2010-09-28 at 13:29 -0500, John Baldwin wrote: > > 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. > > > > I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject some > history here so I can understand why one is "better" than the other? mp_maxid is the variable in the kernel of the maximum possible CPU ID in the running kernel. It is what all kernel code uses for dynamically sized per-CPU arrays such as UMA. It can be smaller than MAXCPU if the platform does not support hotplug CPUs (true for all of our current platforms). maxcpus was only added to export the value of MAXCPU so that user code that uses libkvm to read kernel memory directly can work with datastructures that use statically sized arrays (foo[MAXCPU]) rather than dynamically sized arrays. Aside from that one specific use case, maxcpus should not be used. -- John Baldwin