public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kingsley Cheung <kingsley@aurema.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [Bug 764] New: btime in /proc/stat wobbles (even over 30 seconds)
Date: Fri, 6 Jun 2003 22:08:55 +1000	[thread overview]
Message-ID: <20030606220855.A2888@aurema.com> (raw)
In-Reply-To: <E19OCdo-0006HB-00@gondolin.me.apana.org.au>; from herbert@gondor.apana.org.au on Fri, Jun 06, 2003 at 06:32:04PM +1000

On Fri, Jun 06, 2003 at 06:32:04PM +1000, Herbert Xu wrote:
> Kingsley Cheung <kingsley@aurema.com> wrote:
> > 
> > Attached is a trivial patch to fix the problem against 2.5.70.  I've
> > also attached the trivial 2.4.20 patch I sent to Rusty back for
> > completeness.
> 
> What happens when the system time is changed later on?

Well, without the patch the boottime would change as you change the
system time.  So if you set the system time forward an hour, your
boottime would go forward as well, and so forth.

With the patch, the boottime would remain the same regardless of
changes to the system time.  IMHO, this is probably for the better,
since now as it stands we have issues with the boottime changing under
us due to the way xtime and jiffies are updated.  To me, having an
unchanging boottime is more profitable than one that changes.
Applications could use the value as a reliable absolute time
reference.  For example, to find out the absolute time a process
started, you can add the boottime and the starttime of the process,
the latter being in jiffies after the system booted, and not expect
this value to change.

The tradeoff, though, is that it is possible to have the boottime
greater than the current time if you set the system time back enough.
I think setting it forward is a non-issue.  I could be wrong but so
far I believe that is worth putting up this with tradeoff given the
benefits of an unchanging boottime time.  There is no affect obtaining
the system uptime - people shouldn't go calculating system time minus
boottime, since uptime itself is provided.  Moreover, a similar
problem is what to do with file modification times in the future - we
do nothing.

What do you or others think?  If people wanted to keep the old
semantics of a boottime that changed with the system time then we'll
need another way to avoid the wobble.

--
		Kingsley

  reply	other threads:[~2003-06-06 11:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-02 15:02 [Bug 764] New: btime in /proc/stat wobbles (even over 30 seconds) Martin J. Bligh
2003-06-02 15:08 ` Mike Dresser
2003-06-05  7:19   ` Kingsley Cheung
2003-06-06  2:26     ` Kingsley Cheung
2003-06-06  8:32       ` Herbert Xu
2003-06-06 12:08         ` Kingsley Cheung [this message]
2003-06-12  1:20 ` Kingsley Cheung
2003-06-21  0:34   ` john stultz
2003-06-25 23:47     ` Kingsley Cheung

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030606220855.A2888@aurema.com \
    --to=kingsley@aurema.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox