> On Wed, Aug 6, 2008 at 11:21 AM, John Levon
> <levon@xxxxxxxxxxxxxxxxx> wrote:
> > On Wed, Aug 06, 2008 at 09:09:06AM -0600, Dan Magenheimer wrote:
> >
> >> Again no guarantees but I think we are now under the magic
> >> threshold where the skew is smaller than the time required
> >> for scheduling a VCPU onto a different CPU. If so,
> >> consecutive gethrtime's by the same thread in a domain
> >> should always be monotonic.
> >
> > Right! That sounds positive.
>
> It's an improvement, but I'm pretty sure it's still not sufficient for
> Solaris. If I understand the change correctly, it seems to solve the
> problem for single-vcpu guests on an SMP, but not for multi-vcpu
> guests on an SMP. It sounds like the OS could reschedule a thread
> from VCPU 0 to VCPU 1 and consecutive calls to gethrtime() could still
> return non-monotonic results.
How long does it take for Solaris to reschedule a thread from
VCPU0 to VCPU1? Its certainly not zero time (and you also need
to add the overhead of gethrtime).
But, yes, the same "no guarantees" applies to this situation...
if a Solaris thread continuously calls gethrtime(), there is a
non-zero probability that, if the thread changes physical CPUs
and the thread rescheduling code is "very fast",
two consecutive calls could observe time going backwards. But
that's true with much recent vintage hardware because TSCs
sometimes skew, and so most OS's with high-res timers are able
to deal with this.
True of Solaris, John?
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home