RE: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> > I think a race occurs if 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.  
> 
> That shouldn't matter.  Once the process has (tsc,cpu,version) it can
> use its own local copy of cpu's pvclock parameters to compute the
> tsc->ns conversion.  Once it has that triple, it doesn't matter if it
> gets context-switched; the time computation doesn't depend on what CPU
> is currently running. 
> 
> It only needs to iterate if it gets a version mismatch.  You can
> potentially get a livelock if the version is constantly 
> changing between
> the rdtscp and the get-pvclock-params, and exacerbated if the process
> keeps bouncing between cpus between the two.  But given that the
> rdtsc+get-params should take no more than a couple of microseconds, it
> seems very unlikely the process is sustaining a megahertz CPU 
> migration
> rate.

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.

> And even if it fails, the process always has to be prepared to go to
> some other time source.

And the issue is that there's no way to recognize
failure.  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.

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