[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] RE: [RFC][PATCH] AMD CPU core topology detection



The compute unit is a circuit device which contains 2 cores. Each core has an 
independent integer execution logic and L1 data cache. But L2 cache, FPU, L1 
instruction cache are shared between cores. You can find a description at 
http://tinyurl.com/ygq8jgu. 

The CPUID spec is available at 
http://support.amd.com/us/Processor_TechDocs/25481.pdf.

Thanks,
-Wei

-----Original Message-----
From: dunlapg@xxxxxxxxx [mailto:dunlapg@xxxxxxxxx] On Behalf Of George Dunlap
Sent: Tuesday, January 11, 2011 4:58 AM
To: Huang2, Wei
Cc: Jan Beulich; xen-devel@xxxxxxxxxxxxxxxxxxx; keir@xxxxxxx
Subject: Re: [Xen-devel] RE: [RFC][PATCH] AMD CPU core topology detection

On Fri, Jan 7, 2011 at 3:52 PM, Huang2, Wei <Wei.Huang2@xxxxxxx> 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 
> sibling info is used for scheduler later on. Old AMD CPUs don't have 
> HyperThreading, so the cpu_sibling_map isn't so useful. New CPUs will have 
> core/compute unit/node. Using Intel's HT as an analogy, we have the following 
> relationship: core=>hyper-thread, compute unit=>core, node=>processor). From 
> that perspective, the change is reasonable. But I might have missed other 
> 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 can be 
> treated as thread because it shares FPU with other cores. But different from 
> HT, it also has many dedicated resources (int scheduler, pipeline and L1 
> cache). The scheduler needs more information in order to tell VCPUs apart 
> on-the-fly and schedule them accordingly. Maybe George can take this into 
> consideration for his credit2 scheduler (or beyond).
>
> I will take a look at Linux's implementation. If you have new ideas, I would 
> appreciate them too.
> ]
>
>>@@ -132,6 +132,7 @@
>> #define X86_FEATURE_SSE5      (6*32+ 11) /* AMD Streaming SIMD Extensions-5 
>> */
>> #define X86_FEATURE_SKINIT    (6*32+ 12) /* SKINIT, STGI/CLGI, DEV */
>> #define X86_FEATURE_WDT               (6*32+ 13) /* Watchdog Timer */
>>+#define X86_FEATURE_TOPO_EXT    (6*32+ 22) /* Topology Extension Support */
>
> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.