MAXCPU preparations

[Sean Bruno]

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