lkml.org 
[lkml]   [2008]   [Feb]   [22]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 22 Feb 2008 11:08:20 -0800
FromYinghai Lu <>
SubjectRe: [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


\
 
 \ /
  Last update: 2008-02-22 19:49    [from the cache]
©2003-2008