From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: RE: [RFC][PATCH] AMD CPU core topology detection Date: Tue, 11 Jan 2011 10:58:11 +0000 Message-ID: References: <4D25F227.4060808@amd.com> <4D26E350020000780002AF0B@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Huang2, Wei" Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On Fri, Jan 7, 2011 at 3:52 PM, Huang2, Wei wrote: > [From my understanding, cpu_core_id and phys_proc_id are collected during= boot (mostly in smpboot.c and under cpu/ directory) for sibling map. The s= ibling info is used for scheduler later on. Old AMD CPUs don't have HyperTh= reading, so the cpu_sibling_map isn't so useful. New CPUs will have core/co= mpute unit/node. Using Intel's HT as an analogy, we have the following rela= tionship: core=3D>hyper-thread, compute unit=3D>core, node=3D>processor). F= rom that perspective, the change is reasonable. But I might have missed oth= er parts. Wei, can you point me to some documentation about exactly what the "compute unit" is? > > I will check mce implementation. This is a good point.] > > If indeed your intention was to superimpose the new AMD topology > onto the existing one (partly other than Linux, which added a new > field to struct cpuinfo_x86, but uses cpu_{sibling,core}_map like > what results with your patch), won't there be consequences on (at > least) the credit scheduler (as you may not want cores to be > treated like threads in _csched_cpu_pick())? > > [This is a tricky question. Based on my comments above, Bulldozer core ca= n be treated as thread because it shares FPU with other cores. But differen= t from HT, it also has many dedicated resources (int scheduler, pipeline an= d L1 cache). The scheduler needs more information in order to tell VCPUs ap= art on-the-fly and schedule them accordingly. Maybe George can take this in= to consideration for his credit2 scheduler (or beyond). > > I will take a look at Linux's implementation. If you have new ideas, I wo= uld appreciate them too. > ] > >>@@ -132,6 +132,7 @@ >> #define X86_FEATURE_SSE5 =A0 =A0 =A0(6*32+ 11) /* AMD Streaming SIMD Ext= ensions-5 */ >> #define X86_FEATURE_SKINIT =A0 =A0(6*32+ 12) /* SKINIT, STGI/CLGI, DEV *= / >> #define X86_FEATURE_WDT =A0 =A0 =A0 =A0 =A0 =A0 =A0 (6*32+ 13) /* Watchd= og Timer */ >>+#define X86_FEATURE_TOPO_EXT =A0 =A0(6*32+ 22) /* Topology Extension Sup= port */ > > Would be nice to use the same name as Linux does (i.e. without > the last underscore). > > [I can surely do so.] > > Jan > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >