MAXCPU preparations

[Robert Watson]

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

>
> - Joshua
>
> On Mon, Sep 27, 2010 at 2:42 PM, Robert Watson <rwatson at freebsd.org> wrote:
>>
>> On Mon, 27 Sep 2010, John Baldwin wrote:
>>
>>> Also, I think we should either fix MAXCPU to export the SMP value to
>>> userland, or hide it from userland completely.  Exporting the UP value is
>>> Just Wrong (tm).
>>
>> Well, it's useful in the sense that it tells you what the maximum number of
>> CPUs a kernel can support is, which is helpful, especially if you're futzing
>> with MAXCPU as a kernel option :-).
>>
>> But, more generally, many things that use MAXCPU should probably use either
>> mp_maxid or DPCPU.  Not everything, but most things.
>>
>> Robert
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>>
>