Re: Problems with O(1) scheduler on non-x86 arch's

[James Bottomley]

[e-mail] said:
> in the long term i think the correct approach would be to always store
> the logical CPU number in p->cpu. Architectures that have some strange
> physical numbering can always do a mapping themselves. This way we
> could remove tons of cpu-id conversions from the generic code. And we
> are always going to have these problems, now that the x86 SMP boot
> code renumbers physical CPU ids to match the logical order. 

I can see for something like the x86, where the apic id bears no relationship 
to where the CPU is and there's no support for hot CPU removal, this approach 
may be the correct one.  For Voyager, each CPU has an activity light. So, from 
the physical CPU number, I can tell what the processor is doing, thus it does 
make more sense for me to keep a physical number in p->cpu rather than using 
the logical one.  The voyager architecture is less constrained about ASMP as 
well (I currently run an 8 way box with 4x66MHz and 4x33MHz CPUs).  If I'm to 
use the process or interrupt affinity features, I really need to know 
physically which CPU I want.

Think about the problems logical numbering will cause for hot processor 
removal or failure (if we get around to implementing the feature).  If p->cpu 
is physical, all I have to do is remove the mapping and decrement 
smp_num_cpus, quiesce the processor and redistribute the run queue.  In a 
logically mapped system, I'm going to have to renumber p->cpu in at least one 
other CPUs runqueue as well since the logical mapping code assumes no gaps in 
the 0...smp_num_cpus-1 sequence.

> i've checked the architectures, and besides your architecture it
> appears that only Alpha does a non-identity ID conversion. So it would
> be much cleaner for the generic kernel if we stored the logical CPU id
> in p->cpu, and all SMP interfaces towards lowlevel SMP code used the
> logical CPU ID. 

Actually, the parisc SMP code (on cvs.parisc-linux.org) uses physical 
numbering and it looks to me like the sparc SMP code does as well.

James