From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Roland Subject: Re: Question about hyper-threading of domains Date: Fri, 29 Apr 2005 21:57:56 +0200 Message-ID: <4ad99e05050429125764ad281b@mail.gmail.com> References: <42728E37.2000502@diku.dk> Reply-To: Lars Roland Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <42728E37.2000502@diku.dk> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jacob Gorm Hansen Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 4/29/05, Jacob Gorm Hansen wrote: > hi, >=20 > is it possible, and will it make sense, to allow an SMP-domain access to > both SMT/Hyper threads of a CPU? >=20 > 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 ? >=20 > So quite likely SAS is only interesting if: >=20 > 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. >=20 > 2) You want to run SMT in the domUs. >=20 > 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. >=20 > 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 isolati= on. 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, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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