Messages in this thread | | | From | James Cleverdon <> | Subject | Re: 256 apic id for amd64 | Date | Fri, 7 Jan 2005 17:30:09 -0800 |
| |
Andi has already dealt with some of the coding style issues elsewhere in the thread.
My comment: This is playing with fire. We've gone to considerable trouble to make the boot_cpu_id independent of the physical APIC ID (which is what hard_smp_processor_id() returns). Different BIOSes and different CPU revisions can cause the boot processor to shift.
Examples: We have a box where the boot CPU has an APIC ID of 3. Another system starts with the BSP == 3, but the BIOS renumbers it to zero after first reassigning the original 0 CPU. So, the APIC IDs end up 0, 1, 2, 4. Yet another system assigns the IDs: 0, 1, 6, 7.
We can expect even stranger numbering schemes in the future, given that dual core hyperthreaded CPUs are in the pipeline. Creating any dependency between CPU number and APIC ID is a _bad_ idea.
On Friday 07 January 2005 04:24 am, Andi Kleen wrote: > On Thu, Jan 06, 2005 at 06:53:11PM -0800, YhLu wrote: > > static unsigned int phys_pkg_id(int index_msb) > > { > > return hard_smp_processor_id() >> index_msb; > > } > > > > In arch/x86_64/kernel/genapic_cluster.c > > > > Should be changed to > > > > static unsigned int phys_pkg_id(int index_msb) > > { > > /* physical apicid, so we need to substract offset */ > > return (hard_smp_processor_id() - boot_cpu_id) >> > > index_msb; } > > Why? > > If you want a patch merged you need to supply some more explanation > please. > > Also cc Suresh & James for comment. > > -Andi
-- James Cleverdon IBM LTC (xSeries Linux Solutions) {jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm - 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/
| |