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