From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: Very large value from get_nsec_offset() in timer_interrupt Date: Fri, 21 Apr 2006 11:16:42 -0500 Message-ID: <20060421161642.GA16776@us.ibm.com> References: <20060420224735.GY16776@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20060420224735.GY16776@us.ibm.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: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org * Ryan Harper [2006-04-20 17:47]: > > ns_offset is calculated from get_nsec_offset(). I'm going to dig > a little further, but I wanted to get what I'm seeing out there. static u64 get_nsec_offset(struct shadow_time_info *shadow) { u64 now, delta; rdtscll(now); delta = now - shadow->tsc_timestamp; return scale_delta(delta, shadow->tsc_to_nsec_mul, shadow->tsc_shift); } For some currently unknown reason, now is < shadow->tsc_timestamp; This results in a very large delta value, which is scaled up even larger. The output from the multi-cpu clock info dump doesn't show anything bogus: (XEN) Min = 68672793737292 ; Max = 68672793747633 ; Diff = 10341 (10 microseconds) (XEN) Min = 68899728719792 ; Max = 68899728727283 ; Diff = 7491 (7 microseconds) Any thoughts on why the shadow copy of the tsc_timestamp would be > than the value returned from reading the tsc would be helpful. Very likely this is related to the hardware, this is a 4-node x460 32-way. I've not reproduced this on anything but multi-node setups. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com