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

[Robert Watson]

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