>> If you number each CPU so its two IDs are smp_num_cpus()/2
>> apart, you will NOT need to put some crappy hack in the
>> scheduler to pack your CPUs correctly.
> Which is a major change to the x86 tree and an invasive one. Right now the
> X86 is doing a 1:1 mapping, and I can offer Marcelo no proof that somewhere
> buried in the x86 arch code there isnt something that assumes this or mixes
> a logical and physical cpu id wrongly in error.
I don't think it matters if you do a 1:1 map or not, since the NUMA-Q boxes work
fine without assuming this (I don't use physical APIC id's at all, except for from
the I/O APIC to just broadcast), and I don't think anyone else does either after
It shouldn't be all that hard to check. Mentally mark every time we look at the
physical APIC id, and which variables are set from that and thus "tainted". I
did this once - I don't think it's very many at all.
I don't think changing the order we look at phys_cpu_present_map should
make much of a difference.
On the other hand, relying on the "arbitrary" cpu numbers either way doesn't
seem like the best of ideas ;-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
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 : Sat Dec 15 2001 - 21:00:16 EST