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 <rwat...@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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
