WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: s_time going backwards on same processor?
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Sat, 26 Jul 2008 16:14:24 +0100
Cc: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Delivery-date: Sat, 26 Jul 2008 08:14:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080726085034640.00000008444@djm-pc>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjsRiBvfsM2jSzrTdKQFwbDzvcjiQATHBz4AItzXLAAAV3+8AAJg5QmABCX3iAAAQFaVg==
Thread-topic: s_time going backwards on same processor?
User-agent: Microsoft-Entourage/11.4.0.080122
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