Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Sep 2010 15:06:35 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        sbruno@freebsd.org
Cc:        "freebsd-current@FreeBSD.org" <freebsd-current@freebsd.org>, Robert Watson <rwatson@freebsd.org>, Joshua Neal <jdneal@gmail.com>
Subject:   Re: MAXCPU preparations
Message-ID:  <201009281506.35960.jhb@freebsd.org>
In-Reply-To: <1285699244.2454.63.camel@home-yahoo>
References:  <1285601161.7245.7.camel@home-yahoo> <201009281429.30747.jhb@freebsd.org> <1285699244.2454.63.camel@home-yahoo>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009281506.35960.jhb>