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" >> >Received on Tue Sep 28 2010 - 05:48:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:07 UTC