From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Kernel printk timestamps and walltime drift Date: Fri, 13 Jun 2008 23:09:25 +0100 Message-ID: References: <40B551BEDC7945419A5897958AB3947CB3550C@mtexch.marathontechnologies.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <40B551BEDC7945419A5897958AB3947CB3550C@mtexch.marathontechnologies.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Roger Cruz , dan.magenheimer@oracle.com Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 13/6/08 23:02, "Roger Cruz" wrote: > Was I correct in my understanding on how the timestamp is being obtained > via this call sequence? > > -> vprintk -> printk_clock -> sched_clock -> rdtscll > > In other words, does your patchset use the rdtscll instruction on an > i386, pv, 32-bit linux to compute determine that time? If not, how is > it derived (what file/function should I look at for sched_clock?). The guest calculates current Xen system time based on extrapolating from a Xen-supplied timestamp using current TSC: sys_time = sys_timestamp + (RDTSC - tsc_timestamp) * scale_factor Where three terms on the RHS of the formula are supplied by Xen in the shared_info page, and the fourth is returned by the RDTSC CPU instruction. > While you are right that the only artifact that we have observed is the > drifting timestamps, a future product of ours may need to have an > accurate TSC presentation to the VM and if the time is being derived > from the TSC as I'm conjecturing, then this drift is something we're > going to have to worry about then. Depends what you mean by accurate. PV guests see the underlying host TSC directly. In that sense what they see is 100% accurate! -- Keir > Thank you Keir and Dan