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
|
Home