lkml.org 
[lkml]   [2011]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
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


\
 
 \ /
  Last update: 2011-06-01 22:53    [W:0.054 / U:1.884 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site