WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Export Multicore information

To: "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx>, John Levon <levon@xxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Export Multicore information
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Wed, 13 Dec 2006 08:44:28 +0000
Cc: "Yu, Wilfred" <wilfred.yu@xxxxxxxxx>, Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Yang, Fred" <fred.yang@xxxxxxxxx>, "Mallick, Asit K" <asit.k.mallick@xxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Delivery-date: Wed, 13 Dec 2006 00:44:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <5461330FA59EDB46BE9AB8AAF2C431AD028B427D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Accdfoc0GRLPeHB9QVCU3IZatg004QABSxZgAA83HIgAGIzYkAAcCLcF
Thread-topic: [Xen-devel] [PATCH] Export Multicore information
User-agent: Microsoft-Entourage/11.2.5.060620
On 12/12/06 7:27 pm, "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx> wrote:

>    The most interesting field of the cacheinfo is "shared cpus map".
> Take an example of clowertown. It has 4 cores per socket. Basically
> there are 2 duel-core dies in the packages. So there are 2 pairs of
> cores in the packages which share the L2 caches among the pair itself,
> not across the package.
>    So with this information the end user/admin would have better
> selection when she decides to split the cores from a single package
> across multiple domains.

Hm.... Ok, so we can have cache hierarchies where a single cache is split
among *some* of the threads in a core, or *some* of the cores in a package?
So you end up needing the physical APIC id to be able to apply the CPUID
information and find out *which* siblings are sharing?

I'm still tempted just to provide that APICid info to the guest. Was my
earlier presumption that the cache hierarchy in practice will always be
symmetric correct? Because that could simplify things.

 -- Keir


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