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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

Which clocksource was this with? It would be worth saving the previous tsc
and struct cpu_time values so you can print those out when you see s_time
goes backwards. It'll make it much easier to see what actually went
'backwards' -- also we could run through the 'prev' and 'now' s_time
calculation arithmetic manually to see if any of the arithmetic is at fault.

 -- Keir

On 26/7/08 15:50, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> Thanks Kevin for catching that.  I fixed it using spin_lock_irqsave
> and spin_unlock_irqrestore and have already seen stime going
> backwards... I haven't retested all the clocksources and smp.
> but it doesn't appear that the incorrect enablement of
> interrupts was the problem.
> 
> It's interesting that the problem occurs even with one processor.
> Hopefully that will make it easier to debug.
> 
> Updated debug patch attached.
> 
> Thanks,
> Dan
> 
>> -----Original Message-----
>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>> Sent: Saturday, July 26, 2008 12:51 AM
>> To: Tian, Kevin; dan.magenheimer@xxxxxxxxxx; Xen-Devel (E-mail)
>> Cc: Dave Winchell
>> Subject: Re: s_time going backwards on same processor?
>> 
>> 
>> The code should be using spin_lock_irqsave/spin_unlock_irqrestore.
>> 
>> As it is it's incorrect and could cause odd behaviour. I
>> don't know whether
>> that would extend to seeing time goes backwards as often as
>> Dan reports, but
>> obviously the test has to be re-run.
>> 
>>  -- Keir
>> 
>> On 26/7/08 03:23, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> 
>>> In a quick glimpse, your measure_stime_skew has interrupt
>>> enabled absolutely at exit, instead of restoring previous
>>> setting. Would it be a trouble-maker? I have no latest code
>>> at hand, but at least for what I can check:
>>> 
>>> in local_time_calibration:
>>> 
>>>     local_irq_disable();
>>>     curr_master_stime = read_platform_stime();
>>>     curr_local_stime  = get_s_time();
>>>     rdtscll(curr_tsc);
>>>     local_irq_enable();
>>> 
>>> with your patch, interrupt is enabled after get_s_time, which
>>> then may have curr_tsc read out from a different time point...
>>> 
>>> Thanks,
>>> Kevin
>>> 
>>>> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
>>>> Sent: 2008年7月26日 9:47
>>>> 
>>>> OK, I am definitely recording stime going backwards
>>>> observed with the attached patch.  I have recorded dozens
>>>> over a few hours.  It appears to have no
>>>> obvious pattern between reports, but one thing
>>>> is consistent: In all cases, t->tsc_scale.shift
>>>> is -1.  I'll try to run some more tests over the
>>>> weekend (e.g. with different clocksources... this
>>>> is with clocksource=hpet), but thought I'd report
>>>> what I have seen.  I'm running on a dual-core single
>>>> socket ("Conroe").
>>>> 
>>>> Dan
>>>> 
>>>> P.S. If you try the patch, ensure you set
>>>> the boot parameter "measurestime".
>>>> 
>>>>> -----Original Message-----
>>>>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>>>>> Sent: Wednesday, July 23, 2008 1:06 AM
>>>>> To: dan.magenheimer@xxxxxxxxxx; Xen-Devel (E-mail)
>>>>> Cc: Dave Winchell
>>>>> Subject: Re: s_time going backwards on same processor?
>>>>> 
>>>>> 
>>>>> On 22/7/08 22:58, "Dan Magenheimer"
>>>>> <dan.magenheimer@xxxxxxxxxx> wrote:
>>>>> 
>>>>>> I *do* know that get_s_time() on different processors
>>>>>> can have this behavior and I know it is possible for
>>>>>> hvm_get_guest_time() to go backwards (timer_mode=0),
>>>>>> but I thought s_time was monotonically non-decreasing
>>>>>> on any given processor and that read_platform_stime()
>>>>>> is also monotonically non-decreasing.
>>>>>> 
>>>>>> Does dom0 maybe have direct hardware access to the hardware
>>>>>> platform timer that xen system time is dependent on?
>>>>> 
>>>>> No matter what happens to the underlying platform timer,
>> it should be
>>>>> impossible for Xen system time to go backwards on any given
>>>>> processor. The
>>>>> calibration function never sets the TSC and system timestamps
>>>>> for the next
>>>>> time record any earlier than current TSC value and current
>>>>> computed system
>>>>> time value. Hence it should be impossible for system time to
>>>>> be computed as
>>>>> earlier than that time record.
>>>>> 
>>>>>  -- Keir
>>>>> 
>>>>> 
>>>>> 
>>>> 
>> 
>> 
>> 



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