From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] Adjust time init sequence Date: Fri, 12 Dec 2008 10:10:38 +0000 Message-ID: <494246AE.76E4.0078.0@novell.com> References: <0A882F4D99BBF6449D58E61AAFD7EDD603BB493B@pdsmsx502.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Kevin Tian , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 12.12.08 10:08 >>> >On 12/12/2008 03:40, "Tian, Kevin" wrote: > >> A temp workaround is to move rdtscll(t->local_tsc_stamp) into >> calibrate_tsc_bp, which gives a sane NOW() before percpu time >> init. But then the purpose behind is ambiguous... why would we >> want to count system time from this point? If we can't count >> system time starting from power on, it looks clearer to tag system >> time as 0 when initializing wc_sec/wc_nsec by do_settime. >> Actually the starting point of xen system time is not that critical >> since it's mostly used by relative progress. Then my previous >> updated patch can be used? :-) > >How about rdtscll(t->local_tsc_stamp) at the top of init_xen_time(), and >remove the one I added to early_time_init()? That would allow NOW() usage = at >least in init_xen_time(), and be later than the TSC reset. Perhaps it should be considered to switch to the non-resetting synchronization logic in x86-64 Linux up to 2.6.20 (according to the comments there derived from ia64), or even the current version that doesn't re-write the TSC at all? Jan