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] RE: Saving/Restoring IA32_TSC_AUX MSR

To: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 11 Dec 2009 16:09:56 -0800 (PST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Fri, 11 Dec 2009 16:11:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <EADF0A36011179459010BDF5142A457501D13FE833@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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > Yes, it does.  If there were a reasonable way for an
> > application to check "am I running on a VM for which
> > each vcpu has been pinned?" this might be a reasonable
> > constraint as, if the app isn't, it could fail or at least
> > log a message.  But if the app will randomly fail
> > (or perform horribly) depending on whether the
> > underlying VM is pinned or not (which might even
> > change across a migration or if a sysadmin is
> > "tuning" his data center), I don't think
> > enterprise customers would appreciate that.
> 
> Dan, 
>       If later guest NUMA is implemented, both APP and 
> Hypervisor/Guest are NUMA awared. APP could get benefit
> From the information of node/processor which is got from
> RDTSCP. But how to implement guest NUMA is another story,
> either we can use pin, or something other creative idea.

Right.  A guest NUMA implementation could use:

1) rdtscp+tsc_aux, which is very fast but unreliable
   (unless the app can be certain the guest is permanently
   pinned), or
2) some other yet-to-be-designed mechanism, likely involving
   system calls and/or hypercalls, which is slower but can be
   designed to be always reliable

In my experience in the enterprise world, "slow but
reliable" is always better than "fast but unreliable",
except possibly in well-understood constrained situations.
So I am suggesting we do not implement (1) by NOT
enabling rdtscp-bit-in-cpuid and instead concentrate
on (2).  I guess for the special cases where unreliable
is acceptable, (1) could be an option, but I don't
think it should be turned on by default.

Dan

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