lkml.org 
[lkml]   [2008]   [Jul]   [28]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 28 Jul 2008 10:16:39 +0200
FromIngo Molnar <>
SubjectRe: [git pull] cpus4096 fixes
* Rusty Russell <rusty@rustcorp.com.au> wrote:

> Mike: I now think the right long-term answer is Linus' dense cpumap 
> idea + a convenience allocator for cpumasks.  We sweep the kernel for 
> all on-stack vars and replace them with one or the other.  Thoughts?

The dense cpumap for constant cpumasks is OK as it's clever, compact and 
static.

All-dynamic allocator for on-stack cpumasks ... is a less obvious 
choice.

I dont fundamentally oppose it, but doing that we might be throwing the 
baby out with the bathwater. In many cases having 0.5K on the kernel 
stack is OK. (especially for high-level functions.)

We could do all-dynamic allocations, and it's simpler in many ways (less 
ugly dual-use initialization macros), but it's intrusive for the common 
case. I kind of liked Mike's approach to push the dynamic overhead to 
the less common case - although i dont like all of the end result. 
That's been the driving principle behind the existing patches: dont hurt 
the common case.

Anyway, Mike's solution gives us the option to go in both directions now 
as we've essentially annotated the most difficult on-stack users and 
added a dynamic alloc/free path to them and tested it. Making them all 
dynamic will be easy as it just gets rid of the small-mask 
special-cases.

	Ingo


\
 
 \ /
  Last update: 2008-07-28 10:19    [from the cache]
©2003-2008