[Note: all these changes require some more testing but I wanted to solicit
comments before then, hence the "RFC" in the subject line. -thanks! Mike]

  * Change the genapic->send_IPI_mask function to accept cpumask_t pointer.

  * Add for_each_online_cpu_mask_nr to eliminate a common case of needing
    a temporary on-stack cpumask_t variable.

  * Change send_IPI_mask function in xen to use for_each_online_cpu_mask_nr().

  * Add cpumask_ptr operations.

  * Add get_cpumask_var debug operations.

  * Add global allbutself PER_CPUMASK variable.

  * Remove as many on-stack cpumask_t variables in kernel/sched.c

  * Remove as many on-stack cpumask_t variables in acpi-cpufreq.c

  * Remove as many on-stack cpumask_t variables in io_apic.c


Applies to linux-2.6.tip/master.

Signed-off-by: Mike Travis <travis@sgi.com>
---

-- 
--

[ message continues ]

these changes are certainly looking very nice.

They do interact with a ton of high-flux topics in -tip, so i'd prefer 
to start integrating/testing this straight away (today-ish), before the 
target moves yet again. Are there any showstoppers that speak against 
that?

The plan would be to not keep this in a single topic but to spread them 
into their closest topic (tip/x86/x2apic, tip/irq/sparseirq etc.) - are 
there any cross-topic dependencies to be careful about? Most of the 
commits seem to be standalone. The debug patch would go into 
tip/cpus4096.

And more generally: how far away are we from being able to introduce 
struct cpumask and hide its implementation from most .c files? That 
would be rather efficient in preventing it from being put on the stack 
spuriously in one of the 30+ thousand Linux kernel source code files. 
Just like we hide the true structure of things like 'struct kmem_cache' 
and force them to always be used as pointers.

	Ingo
--

[ message continues ]

What I'll do is resubmit the changes that have nothing to do with
cpumask_ptr's first as they are mostly just "cleaning up extraneous
temp cpumask variables".  Then I'll try the redefine of cpumask_t to
see what kind of hornet's nest is opened up.

What do you think of a pool of temp cpumask_t's?  That way, they
could be made available early (before kmalloc is available).  An
atomic op could be used for reservation which when the zero-based
percpu variables finally get completed, become very low cost.

Thanks,
Mike
--

[ message continues ]