Re: x86_64: apic id lift patch
From: Andi Kleen
Date: Mon Nov 21 2005 - 17:24:07 EST
On Mon, Nov 21, 2005 at 02:17:35PM -0800, yhlu wrote:
> > Can you please explain clearly:
> > - What are you changing.
> 1. use core_vir instead of x86_max_cores, for E0 later single core,
> core_vir could be 2, and x86_max_cores still is 1. So it makes node
> calculation right.
max_cores should be 2 here.
> > - What was the problem with the old behaviour
> 1. for E0 single core, node 2, initial apicid is 4, and old cold will
> get node=4 instead of 2.
> 2. if the lifted apicid is not continous, it will assign strange node
> id to the cpu.
Is there a good reason in the BIOS to not make it contiguous?
> > - Why that particular change
> 1. We can get exact node id and core id from initial apicid for E0 later.
> > - Why can't that APIC number setup not be done by the BIOS itself
> 1. That patch the code more generic. and don't assume the lifted
> apicid is continous.
It's only the last resort fallback anyways. I would prefer to not
make it more complicated. The recommend way is you supplying
a SRAT table, then you're independent of any such fallback heuristics
and just tell the kernel the right mapping.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/