Re: [Bug 764] New: btime in /proc/stat wobbles (even over 30

john stultz (johnstul@us.ibm.com)
20 Jun 2003 17:34:39 -0700


On Wed, 2003-06-11 at 18:20, Kingsley Cheung wrote:

> I see that there has been a fix made for this since 2.5.70-bk13 or
> 2.5.70-bk14 that solves this problem by using the seqlock to ensure
> that the jiffies and time of day are atomically read.

And further then that, we loose less precision in some of the math so we
don't have the single second wobbles that were initially seen.

> However, wouldn't it be better to have the boottime calculated only
> once so that it is independent of changes in the system time that may
> occur later? Even with the fix with seqlock, the boottime can still
> change back or forwards whenever the system time is set back or
> forwards. IMHO an unchanging boottime that is independent of the time
> of day is the best approach. Maybe something like the patch against
> 2.5.70-bk14 that I've attached.
>
> What do people think?

Really, I'm fine with the current semantics. At boot time the system
clock may not have been correct, and was corrected only after NTP
started up later in the boot sequence. So you could have some very funky
btimes.

Even the current definition of btime = now - uptime has its own quirks
(when systems are suspended uptime doesn't increment, etc) but I think
its more likely to be correct then any other method (assuming the time
now is more accurate then time at boot thanks to ntp or whatnot).

I'm curious, how are people using the btime value? I'd think uptime and
gettimeofday would be more useful bits of info, so I'd like to hear
more.

thanks
-john

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/