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: if (sysctlbyname("kern.smp.maxcpus", &maxcpus, &size, NULL, 0) < 0) { [...] if (maxcpus > MEMSTAT_MAXCPU) { list->mtl_error = MEMSTAT_ERROR_TOOMANYCPUS; return (-1); } 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. - 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 Mon Sep 27 2010 - 21:56:11 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:07 UTC