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] Question about hyper-threading of domains

To: Jacob Gorm Hansen <jacobg@xxxxxxx>
Subject: Re: [Xen-devel] Question about hyper-threading of domains
From: Lars Roland <lroland@xxxxxxxxx>
Date: Fri, 29 Apr 2005 21:57:56 +0200
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 29 Apr 2005 19:57:38 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mwvV3JaDTD+BAGqZM8Gx0b28J0rMMKvUaurvchTxV3jP/KeZi5h7fRWKJrdCHNYWPQQ+/Sya8OQNuRWf28tudnpxVTxY+0y1jaDEr1WIfmyufnfFZGUfLe8KqyOTuYRX66hDzCzriDDOVWDqan2jS7p310hWpOehQ69/M1/KO4M=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <42728E37.2000502@xxxxxxx>
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>
References: <42728E37.2000502@xxxxxxx>
Reply-to: Lars Roland <lroland@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 4/29/05, Jacob Gorm Hansen <jacobg@xxxxxxx> wrote:
> hi,
> 
> is it possible, and will it make sense, to allow an SMP-domain access to
> both SMT/Hyper threads of a CPU?
> 
> My performance measurements of the small address spaces implementation
> (SAS) seem to indicate that having the driver domain in a separate hyper
> thread is still a little faster than SAS for a non-SMP/SMT domU.  I
> guess that means that that SMT IPIs are about the same cost as ring
> switches.

Seans fair enough - Out of curiosity have you published these
measurements anywere ?

> 
> So quite likely SAS is only interesting if:
> 
> 1) You don't have SMT (luckily, I have a bunch of machines like that
> back home ;-)). Do the recent Opterons and Itaniums have SMT btw?

No neither the latest Opterons nor the Itaniums have explicit SMT.

> 
> 2) You want to run SMT in the domUs.
> 
> 3) You give up driver isolation and manage to get dom0 running in ring0
> (to remove the cost of ring switches). Some comments in the Xen code
> indicate that this will be hard to do, so it may not be worth it.
> 
> I previously stated that using small address spaces means giving up
> driver isolation, but I think that with the right use of segments that
> should not be necessary, so there is no trade-off with regards to isolation.

Could you explain a little further how excalty you plan to avoid this
- I have been digging into this myslef and It is not obvious to me how
this can be achived,

> 
> My patch to Xen and XenLinux is fairly small, though a few things
> (mainly the PERDOMAIN mapping and thus use of segments in domains) are
> not handled correctly at this point. Also, I do not use segments to keep
> domUs out of dom0, which I will at some point.
> 
> Basically, I have added per-domain pgd lower and upper bounds, and I
> have added an extra pgd slot for the linear page tables of dom0. The
> linear_* macros now take an exec_domain* as argument, and I have a
> pgd-version check in __context-switch() that potentially updates the
> cached entries at the top of the domUs pgd, and does nothing (i.e. does
> not write cr3) otherwise.  If needed, I flush the TLB before
> pdg-updates,  and when unpinning a pgd I clear the cached area before
> put_page() and friends.
> 
> Most of the changes are of a nature that could be made applicable to
> other architectures as well. I think they could be activated at run-time
> with little or no overhead when not in use.
> 
> I would be happy to share my changes with anyone interested.

Yes please - I have the time (and hardware) to check this.


Regards.

Lars Roland

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