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
|
Home