MAXCPU preparations

[Robert Watson]

On Mon, 27 Sep 2010, Sean Bruno wrote:

>> wouldn't it be better to do a sysctlbyname() and use the real value for the 
>> system?

libmemstat contains some useful sample code showing how this might be done.

> That was my initial thought (as prodded by scottl and peter).
>
> If it is made dynamic, could this be opening a race condition where the call 
> to sysctlbyname() returns a count of CPUS that is in turn changed by the 
> offlining of a CPU?  Or am I thinking to much about this?

Yes, you are.  MAXCPU is a compile-time constant for kernel builds, so (at 
least a the world is today), that can't happen.

I think there's a reasonable argument that MEMSTAT_MAXCPU should be phased out 
and all internal structures in libmemstat should be dynamically sized. 
However, core counts aren't growing that fast, and it's quite a bit of work, 
and probably not worth it just yet.

I'm somewhat averse to using MAXCPU in libmemstat, however, because MAXCPU is 
actually not a constant in the general case: FreeBSD/i386, for example, 
regularly uses two different values: 1 for !SMP kernels, and 32 for SMP 
kernels.  That's why libmemstat encodes its own value, for better or worse.

A reasonable alternative would be to replace 32 with MAXCPU * 2, or if we're 
feeling particularly optimistic, MAXCPU * 4.  Or just another big number, like 
256.

Robert