>> Hmmm ... 2.5.43-mm2 and 2.5.44 work fine, but 2.5.44-mm1 (and mm2)
>> panic consistently on boot for a 16 way NUMA-Q.
>>
>> Normally this box will boot with TSC on or off. If anyone has any pointers as
>> to what's changed in the mm patchset going from 43-mm2 to 44-mm1 that
>> might have touched this area (I can't see anything), please poke me in the
>> eye. Otherwise I'll just keep digging into it ....
>>
>
>
> Is possibly the code which defers the allocation of the per-cpu
> memory until the secondary processors are being brought online.
Aha ... ;-) thanks for the pointer. Will poke at that.
> I've decided to toss that. It's causing some grief for architectures,
> and only buys us 10k * (NR_CPUS - nr-cpus) worth of memory anyway.
Hmmm ... I guess people with SMP normally have lots of RAM anyway,
and those few that care could just config NR_CPUS down. Shame though,
automagical is much nicer. Maybe we can work out exactly why it's broken
instead.
> Well. It would be useful for NUMA to be able to place the per-cpu storage
> into node-local memory. But the code doesn't do that. It just uses
> kmalloc on the boot cpu, and we don't have an alloc_pages_for_another_cpu()
> API..
Well at a page granularity level you have alloc_pages_node(cpu_to_node).
I suppose technically that's not guaranteed, but on boot it'll never fall back.
If you need it in permanent KVA, you can remap it into the vmalloc reserve
area.
Why do you need to do it that late, should be able to do it once you've parsed
mptables? alloc_bootmem / alloc_bootmem_node ?
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:01:01 EST