Re: [RFC 00/13] smp: reduce stack requirements for genapic send_IPI_maskfunctions

From: Mike Travis
Date: Mon Sep 08 2008 - 11:17:19 EST

Ingo Molnar wrote:
> * Mike Travis <travis@xxxxxxx> wrote:
>> [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]
> 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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at