[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTiniq6GVMJPO_-efKrWHQg9V9Dod9g@mail.gmail.com>
Date: Wed, 1 Jun 2011 14:50:52 -0600
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: John Stultz <johnstul@...ibm.com>,
Thomas Gleixner <tglx@...utronix.de>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: /proc/stat btime accuracy problem
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. Then, when userland fixes xtime, in my
case with "hwclock --hctosys", the delta is applied to both xtime and
wall_to_monotonic. The result is that "btime" is no longer accurate.
Here's an example where I artificially exaggerated the problem by
adding 30 seconds of wait time with interrupts disabled. Assume the
RTC is perfectly correct at boot, and note that xtime has fallen
behind the RTC by 31 seconds by the time userland resets the clock:
rtc 1306957603 xtime 1306957603 wall_to_monotonic -1306957603 in
timekeeping_init()
rtc 1306957638 xtime 1306957607 wall_to_monotonic -1306957603
before do_settimeofday()
rtc 1306957638 xtime 1306957638 wall_to_monotonic -1306957634 after
do_settimeofday()
Now /proc/stat btime reports 1306957634 instead of the correct 1306957603.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists