From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 20:01:35 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 BACE81065693; Tue, 28 Sep 2010 20:01:35 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5D78FC08; Tue, 28 Sep 2010 20:01:35 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o8SJnSjG095765; Tue, 28 Sep 2010 12:49:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type:date: message-id:mime-version:x-mailer:content-transfer-encoding; b=LKF49Ljv45PEGT2+dQsVX9SahDoisldbxJtr6Fobq/7f+ZhaQcAadT8FzufhumYS From: Sean Bruno To: John Baldwin In-Reply-To: <201009281506.35960.jhb@freebsd.org> References: <1285601161.7245.7.camel@home-yahoo> <201009281429.30747.jhb@freebsd.org> <1285699244.2454.63.camel@home-yahoo> <201009281506.35960.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 28 Sep 2010 12:49:28 -0700 Message-ID: <1285703368.2454.64.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 28 Sep 2010 20:11:40 +0000 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 20:01:35 -0000 On Tue, 2010-09-28 at 14:06 -0500, John Baldwin wrote: > 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. > ah, I see now. sys/kern/subr_smp.c::mp_maxid is exported via the systcl kern.smp.maxid thank you for clarifying. Sean