lkml.org 
[lkml]   [2008]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
David Miller wrote:
> From: Ingo Molnar <mingo@elte.hu>
> Date: Tue, 26 Aug 2008 09:22:20 +0200
>
>> And i guess the next generation of 4K CPUs support should just get away
>> from cpumask_t-on-kernel-stack model altogether, as the current model is
>> not maintainable. We tried the on-kernel-stack variant, and it really
>> does not work reliably. We can fix this in v2.6.28.
>
> I recently did some work on sparc64 to use cpumask pointers
> as much as possible.
>
> The only case that didn't work was due to a limitation in
> arch interfaces for the new generic smp_call_function() code.
> It passes a cpumask_t instead of a pointer to one via
> arch_send_call_function_ipi().
>
> But other than that, the whole sparc64 SMP stuff uses cpumask_t
> pointers only.
>
> What it comes down to is that you have to do the "self cpu"
> and other tests in the cross-call dispatch routines themselves,
> instead of at the top-level working on cpumask_t objects.
>
> Otherwise you have to modify cpumask_t objects and thus pluck
> them onto the stack where they take up silly amounts of space.

Yes, I had proposed either modifying, or supplementing a new
smp_call function to pass the cpumask_t as a pointer (similar
to set_cpus_allowed_ptr.) But an ABI change such as this was
not well received at the time.

Thanks,
Mike


\
 
 \ /
  Last update: 2008-08-26 21:09    [W:0.194 / U:1.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site