Messages in this thread | | | Date | Thu, 18 Nov 2010 09:30:45 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 4/9 UPDATED-1] x86: Initialize 32bit logical apicid mapping early during boot |
| |
* Tejun Heo <tj@kernel.org> wrote:
> On x86_32, non-standard logical apicid mapping can be used by > different NUMA setups and the mapping is queried while bringing up > each CPU using apic->cpu_to_logical_apicid() to build > cpu_2_logical_apicid[] array. The logical apicid is then used to > deliver IPIs and determine NUMA configuration. > > Unfortunately, initializing at SMP bring up is too late for percpu > setup making static percpu variables setup w/o considering NUMA. This > also is different from how x86_64 is configured making the code > difficult to follow and maintain. > > This patch updates logical apicid mapping handling such that, > > * early_percpu variable x86_cpu_to_logical_apicid replaces > cpu_2_logical_apicid[]. > > * apic->cpu_to_logical_apicid() is called once during get_smp_config() > and the output is recorded in x86_cpu_to_logical_apicid. > > * apic->cpu_to_logical_apicid() is allowed to return BAD_APICID if it > can't determine the value that early during boot. In this case, the > mapping will be initialized during SMP bring up by reading APIC LDR > as before. > > - Brian Gerst spotted that setup_per_cpu_areas() was not copying the > early x86_cpu_to_logical_apicid to the permanent percpu area and > es7000_32 is using per_cpu() instead of early_per_cpu(), which in > itself is not incorrect as they're never used before setup_per_cpu() > but still confusing. Both updated. > > - Using local variable @cpu to cache smp_processor_id() in > setup_local_APIC() separated out into a separate patch as suggested > by Yinghai Lu.
This patch is still _WAY_ too large.
Also, these:
> +#ifdef CONFIG_X86_32 > +#endif
> +#ifdef CONFIG_X86_32 > +#endif
> +#ifdef CONFIG_X86_32 > +#endif
> +#ifdef CONFIG_X86_32 > +#endif
Are rather ugly.
Ingo
| |