Re: [PATCH] hwpmc(4) changes to use 'mp_maxid' instead of 'mp_ncpus'.

On Sat, 15 Mar 2008, Joseph Koshy wrote:

Therefore we can use either a count (mp_ncpus) or a maximum id (mp_maxid) to represent {MACHINE-MAX}, but either one would do.

However, x86 MD code uses both, with newer code seeming to prefer mp_maxid. So I am puzzled. There are far more uses of mp_ncpus there though.

I suspect that's because kernel code wants to index into a data structure using the CPU ID, i.e., curcpu, but don't want to size the array at MAXCPU, which will be an increasingly large compile-time constant over time. This relies on the relative non-sparseness of CPU IDs to be of benefit, and generally, this does hold. For example, on the HTT boxes, CPU IDs might be 0..3 with 0 and 2 being used, and that's still less than 16 or 32. However, in some cases we size kernel arrays to MAXCPU, and sometimes to mp_maxid. There's a reasonable argument that sizing arrays this way is a dubious practice as you more ideally want to store per-CPU data hung off the percpu block to avoid adjacent per-cpu data in the same cache line.

I ran into some similar concerns when trying to figure out how best to export memory allocator statistics from the kernel. In the end what I concluded was that I would export contiguous CPU data up to mp_maxid from the kernel, and that userspace would try to avoid any compile-time knowledge of CPU limits so that it doesn't matter if a kernel is compiled for UP (MAXCPU=1) or SMP (MAXCPU=(n), where n is often 16, I believe). I do end up exporting data for absent CPUs under mp_maxid.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages