Messages in this thread |  | | | Date | Fri, 22 Feb 2008 11:08:20 -0800 | | From | Yinghai Lu <> | | Subject | Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box |
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@Sun.COM> 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
|  |