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

Re: [Xen-devel] [PATCH] Adjust time init sequence

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Adjust time init sequence
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 10 Dec 2008 13:49:19 +0000
Cc:
Delivery-date: Wed, 10 Dec 2008 09:00:46 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0A882F4D99BBF6449D58E61AAFD7EDD601E23C85@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: AclayLVCCL6aQHvlSCiWfWMkyOK68AABWP7w
Thread-topic: [Xen-devel] [PATCH] Adjust time init sequence
User-agent: Microsoft-Entourage/12.14.0.081024
Is it really safe to use NOW() before init_percpu_time()? Seems dodgy.

Since calibration points are sync'ed across all CPUs on Xen 3.3 and
unstable, trying to ensure that the first calibration period across all CPUs
is equal is a lost cause isn't it?

 -- Keir

On 10/12/2008 13:10, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> Adjust time init sequence
> 
> percpu timer init for BSP happens within init_xen_time,
> while CMOS access at end may take up to 1s. This may
> make 1st trigger to calibration timer happens >1s interval
> and elapsed local stime for BSP also exceed 1s. However
> percpu timer init happens after that point for APs, which
> will then have a <1s elapsed local stime at 1st calibration.
> That leads to distinct mul_frac among cores, which can
> cause up to 6ms system time skew in the start. This is
> not big issue, since gradually xen calibration framework
> closes that gap. But it's still better to avoid that big
> skew in early boot phase.
> 
> Signed-off-by Kevin Tian <kevin.tian@xxxxxxxxx>
> 
> diff -r 85b2f4aafea4 xen/arch/x86/time.c
> --- a/xen/arch/x86/time.c Tue Dec 09 20:56:23 2008 -0500
> +++ b/xen/arch/x86/time.c Tue Dec 09 22:21:07 2008 -0500
> @@ -1095,7 +1095,7 @@
>  
>      local_irq_save(flags);
>      rdtscll(t->local_tsc_stamp);
> -    now = !plt_src.read_counter ? 0 : read_platform_stime();
> +    now = read_platform_stime();
>      local_irq_restore(flags);
>  
>      t->stime_master_stamp = now;
> @@ -1118,12 +1118,13 @@
>  
>      open_softirq(TIME_CALIBRATE_SOFTIRQ, local_time_calibration);
>  
> -    init_percpu_time();
> +    do_settime(get_cmos_time(), 0, 0);
>  
>      stime_platform_stamp = 0;
>      init_platform_timer();
>  
> -    do_settime(get_cmos_time(), 0, NOW());
> +    /* init bsp percpu time after platform timer initialized, similar as AP
> */
> +    init_percpu_time();
>  
>      return 0;
>  }
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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