Re: [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation

[Paul Jackson <pj@sgi.com>]

On Fri, Jun 04, 2004 at 11:42:19AM -0700, Paul Jackson wrote:
> I don't see why user code needs to determine NR_CPUS exactly.

William Lee Irwin III replied:
> Wrong. Apps that want to reconfigure the system to e.g. online more cpus
> in response to heightened load want to know.

Earlier, Andrew Morton wrote:
> Sometimes userspace wants to know NR_CPUS.  Sometimes it wants ...


I disagree, Andrew and William.

What the kernel should provide user space is:

 * cpu_possible_map - which CPU's are possible at all
 * cpu_present_map  - which CPU's are presently plugged in
 * cpu_online_map   - which CPU's are online for scheduling
 * other more specific maps, such as perhaps perfctr stuff
 * the size of these maps, for dynamic allocation

See further the include/linux/cpumask.h file in my recent patch set for
consolidated documentation of these maps.

Currently, in the HOTPLUG configuration, cpu_possible_map happens to be
just all the CPUs from 0 to NR_CPUS-1 (i.e. CPU_MASK_ALL), but that is a
detail of the current implementation that should _not_ be used to drive
the design of what we expose to user space.

The other stuff Andrew mentions, such as max CPU number possible or
whatever, can and should be computed by user space code, from the above.

Just knowing NR_CPUS won't be much use to hotplug user code,
except as an overly specific way to determine the size of these maps.

The size of the CPU maps could be in bytes (the usual sizeof unit) or
for the present format, in number of unsigned longs.  Probably bytes is
less surprising, even though it's slightly overly specified (the bottom
2 or 3 bits will always be zero).

I see no reason why user space needs to distinguish between NR_CPUS == 8
and NR_CPUS == 4, say, beyond what is visible in such maps as above. And
if at any time one of the maps is sparse, then a single small integer
such as NR_CPUS is immediately inadequate.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373