From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759144Ab1FAXf4 (ORCPT ); Wed, 1 Jun 2011 19:35:56 -0400 Received: from smtp-out.google.com ([216.239.44.51]:32482 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752395Ab1FAXfy convert rfc822-to-8bit (ORCPT ); Wed, 1 Jun 2011 19:35:54 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=TiWmuFjEVkOgz3S5YhR4wpGUjTyQ8jReOJOlD2Cl3VCtwVFKGwvgO98bWq7IFzQcqm +kOPuhztrHNicqbzqXAw== MIME-Version: 1.0 In-Reply-To: <1306967733.11492.11.camel@work-vm> References: <1306967733.11492.11.camel@work-vm> From: Bjorn Helgaas Date: Wed, 1 Jun 2011 17:35:22 -0600 Message-ID: Subject: Re: /proc/stat btime accuracy problem To: john stultz Cc: Thomas Gleixner , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 1, 2011 at 4:35 PM, john stultz wrote: > On Wed, 2011-06-01 at 14:50 -0600, Bjorn Helgaas wrote: >> timekeeping_init() basically does the following: >> >>     xtime = RTC >>     if (arch implements read_boot_clock()) >>         wall_to_monotonic = -read_boot_clock() >>     else >>       wall_to_monotonic = -xtime >> >> So wall_to_monotonic records some approximation of the system boot >> time, which is then used to derive the "btime" reported in /proc/stat. >> >> The problem I'm seeing is that xtime is updated on timer ticks, so >> uninterruptible code, like kernel serial printk, makes us miss ticks, >> so xtime falls behind the RTC. > > Huh. So this sort of issue was common back when we had tick-based > timekeeping (in combination with troubled hardware), but with the > current clocksource based timekeeping, occasional lost ticks shouldn't > really effect time. Makes sense. Your presentation here was a great help: http://sr71.net/~jstultz/tod/ols-presentation-final.pdf > Can you explain a bit more about what kind of hardware this is happening > on, and what clocksource is being used? Sure. This is an x86 box. Normally we're using the TSC clocksource, and I don't think the issue happens after that. I guess my experimentation so far has been with uninterruptible time before we register *any* clocksource (or at least before I see any "Switching to clocksource" messages). Bjorn