Re: [PATCH] i386 !NUMA node_to_cpumask broken in early boot

> Thanks for the feedback, ugly indeed, i was really trying to avoid adding 
> a new API function or extra cpu_* variables. Ok, here is an 
> early_node_to_cpumask instead.

Thinking about it again it's most likely broken with CPU hotplug anyways
whatever you're doing. So how does your code handle adding new 
CPUs?  If it does can the normal CPU bootup be handled in the 
same way. Then this wouldn't be needed at all.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• Follow-Ups:
  • Re: [PATCH] i386 !NUMA node_to_cpumask broken in early boot
    • From: Zwane Mwaikambo <[email protected]>

• References:
  • [PATCH] i386 !NUMA node_to_cpumask broken in early boot
    • From: Zwane Mwaikambo <[email protected]>
  • Re: [PATCH] i386 !NUMA node_to_cpumask broken in early boot
    • From: Andi Kleen <[email protected]>
  • Re: [PATCH] i386 !NUMA node_to_cpumask broken in early boot
    • From: Zwane Mwaikambo <[email protected]>

• Prev by Date: Re: [PATCH] i386 !NUMA node_to_cpumask broken in early boot
• Next by Date: Re: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6
• Previous by thread: Re: [PATCH] i386 !NUMA node_to_cpumask broken in early boot
• Next by thread: Re: [PATCH] i386 !NUMA node_to_cpumask broken in early boot
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]