Re: Linux 2.4.17-pre5

[Martin J. Bligh]

>> 	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
we boostrap.

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 ;-)

Martin.