RE: [Xen-devel] s_time going backwards on same processor?

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

Hi Kevin --

All good questions.  I used a modified version of
the skew measurement code I posted the other day
and noticed it by accident.  It could have been
an artifact of my debugging code, but I have lost
access to my test machine for a few days so I
can't reproduce it right now.  If I can reproduce
it, I will test for some of your questions.
However, I had previously tested on this machine
for cpufreq changes and time stop/start calls and
neither were present.

Dan

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> Sent: Wednesday, July 23, 2008 12:16 AM
> To: dan.magenheimer@xxxxxxxxxx; Xen-Devel (E-mail); Keir Fraser
> Cc: Dave Winchell
> Subject: RE: [Xen-devel] s_time going backwards on same processor?
>
>
> >From: Dan Magenheimer
> >Sent: 2008年7月23日 5:59
> >
> >Are there any conditions/events in a running Xen system
> >that can cause two consecutive calls to get_s_time()
> >*on the same processor* to return values such that
> >the second one is smaller than the first (other than
> >64-bit wraparound)?  I ask because I'm fairly sure
> >that I observed this, and Xen system time on the
> >same processor moved backwards about 40us (40000ns).
>
> Weird. Did you observe same phenomenon by putting
> your test code in any code path, or just on some specific
> point?
>
> Does clocksource matters?
>
> Did you enable any cpufreq or cpuidle feature?
>
> Only observed on SMP Xen?
>
> Thanks,
> Kevin
>

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