/proc/stat btime accuracy problem

[Bjorn Helgaas]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/