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

Re: [Xen-devel] Question about hyper-threading of domains


  • To: Jacob Gorm Hansen <jacobg@xxxxxxx>
  • 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=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

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