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] rdtscP and xen (and maybe the app-tsc answer I've been l

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 21 Sep 2009 17:11:56 -0700 (PDT)
Cc: kurt.hackel@xxxxxxxxxx, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Mon, 21 Sep 2009 17:12:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AB81289.8040604@xxxxxxxx>
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, I neglected an important pre-condition.  ASSUME the first
> > rdtscp on pcpu-A gets a version mismatch so that it must fetch
> > the parameters again.  Then: the vcpu switches pcpu TWICE
> > from pcpu-A to pcpu-B and back to pcpu-A and does rdtscp
> > each time on pcpu-A but reads one or more pvclock parameters
> > (that are too big to be encoded in TSC_AUX) on pcpu-B.
> >
> > I agree that this is vanishingly low probability but on
> > a pcpu-oversubscribed machine I think it only takes one
> > vcpu-to-pcpu reschedule and then a poorly timed interrupt that
> > causes the vcpu to be unscheduled, and then later rescheduled
> > on the original processor.
> >   
> 
> Sure.  It just has to keep iterating until it gets consistency.  If it
> iterates too long (10 times?  100? 1000?) it should give up and assume
> something is inherently broken.

No, I'm not talking about iteration.  In the scenario I'm
trying to describe, the version number hasn't changed on
pcpu-A so the algorithm doesn't iterate.

> On the other hand, using the tsc as part of a larger ABI 
> works reliably.
> 
> This rdtscp proposal is basically the latter, as a variant of the
> pvclock algorithm.  I'm mostly interested in it as an 
> implementation for
> vsyscall etc, rather than something that apps would use directly.
> 
> >  Unless... wait... are you assuming that
> > every unscheduled period results in an adjustment
> > of the pvclock offset parameter?  That results in
> > "nanoseconds since guest boot during which any
> > vcpu is running" rather than "nanoseconds since
> > guest boot even when all vcpus are idle", right?
> > That's different than what I had in mind, but I
> > suppose it works.
> >   
> 
> Not following you here.

I realized after I sent this that I'm not really sure
I understand the pvclock implementation, particularly
under what circumstances the version number changes
or doesn't.  And if this is different in any way
than the versions you are proposing that the app
would see.  So I'm not positive we are considering
the same cases.

Dan

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

<Prev in Thread] Current Thread [Next in Thread>