Re: [PATCH] x86_64: make amd quad core 8 socket system not beclustered_box
From: Yinghai Lu
Date: Fri Feb 22 2008 - 13:46:55 EST
On Friday 22 February 2008 11:02:30 am Yinghai Lu wrote:
> On Friday 22 February 2008 04:25:18 am Andi Kleen wrote:
> > Yinghai Lu <Yinghai.Lu@xxxxxxx> writes:
> >
> > > quad core 8 socket system will have apic id lifting.the apic id range could
> > > be [4, 0x23]. or [8, 0x27]. apic_is_clustered_box will think that need to three clusters
> > > and that is large than 2. So it is treated as clustered_box.
> > >
> > > and will get
> > >
> > > Marking TSC unstable due to TSCs unsynchronized
> > >
> > > even the CPUs have X86_FEATURE_CONSTANT_TSC set.
> > >
> > > this patch offset back the apic before get apic clusterid.
> > >
> > > or use dmi to get apic_is_clustered?
> >
> > The clustered check is for Summit and es7000 systems
> > On 64bit systems it might be actually possible to trigger
> > this based on SLIT instead. But you'll need to check with
> > the IBM Summit/Unisys es7000 developers if that works or not
> >
> > If you don't want to do that the safer way would be probably
> > the check if there are holes between the CPUs APIC numbers.
> > If yes then it's likely clustered mode. I think that would
> > be better than to disable it unconditionally for apic lifting
> > like your patches does.
>
> so for that box [4, 0x23] still could be apic clustered? there is a hole [0,3]..
>
> is their box using AMD cpu or not?
or move
CPUs have X86_FEATURE_CONSTANT_TSC check before apic_clustered check?
YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/