Re: [patch] genapic: optimize & fix APIC mode setup

[Ashok Raj <ashok.raj@intel.com>]

On Mon, Nov 13, 2006 at 07:42:56PM +0100, Ingo Molnar wrote:
> 
> * Siddha, Suresh B <suresh.b.siddha@intel.com> wrote:
> 
> > > for that i'd have to know the bug, and this is the third time i'm 
> > > asking about specifics :-) (The URL that was given in the thread was 
> > > about a chipset bug regarding incompatibility with clustered-APIC 
> > > mode - my patch in fact - because it switches small systems to use 
> > > logical flat mode always - solves that kind of regression too.)
> > 
> > Not really. That chipset belongs to a MP platform and with your 
> > proposed patch, we will endup using clustered APIC mode and will hit 
> > the issue(in the presence of cpu hotplug) mentioned in that URL.
> 
> hm, why does it end up in clustered mode? Cluster mode should only 
> trigger if the APIC IDs go beyond 16.

number of cpus >8 we need to switch to either clustered or flat physical mode.

> 
> but i'd be fine with never going into cluster mode, instead always using 
> physical flat mode when having more than 8 APICs (independent of the 
> presence of CPU hotplug). On small systems, logical flat mode is what is 
> the best-tested variant (it's also slightly faster).
> 
> 	Ingo

I think we choose flat physical mode for two reasons, x86_64 was doing the same
so we were consistent with the approach. The other was when we have cpu hotplug
enabled its difficult to say what the max number of cpus will be. So
choosing flat logical was not right even if we had 8 or less cpus, and 
technically we could think of something that starts with less and go beyond 
max cluster limit of 60 as well.

Hence Andi introduces another way to limit it based on disabled cpu count in 
MADT, or user can specify at startup time to specify the limit of potentially
hot-pluggable cpus.

bigsmp was also a relatively new variant at the time, and all agreed to keep
things simple instead of having 3 different approaches, (logical flat,
logical cluster, and flat physical). Running some simple tests we didnt
see any appreciable differences at that time, maybe we were not that exhaustive.



-- 
Cheers,
Ashok Raj
- Open Source Technology Center
-
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/