All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eli Carter <eli.carter@inet.com>
To: Russell King <rmk@arm.linux.org.uk>,
	Jamie Lokier <lk@tantalophile.demon.co.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: gettimeofday question
Date: Wed, 21 Mar 2001 16:27:13 -0600	[thread overview]
Message-ID: <3AB92AC1.DF054E2E@inet.com> (raw)
In-Reply-To: <200103192134.VAA01785@raistlin.arm.linux.org.uk> <3AB927D0.F152717D@inet.com>

Eli Carter wrote:
> 
> Russell King wrote:
> >
> > Eli Carter writes:
> > > What are you seeing that I'm missing?
> >
> > Ok, after sitting down and thinking again about this problem, its not
> > the 9.9999ms case, but the 10.000000001 case:
> [snip]
> > Like I say, this requires good timing to create, so may not be too much of
> > a problem, but it does seem to be a problem that could occur.
> 
> It appears that this problem is easier to create than we originally gave
> credit for....  All that is needed is for gettimeoffset() not to be
> called for a _minimum_ of >10ms, and for the timer to wrap during a call
> to do_gettimeofday() or during a period of time where interrupts are
> disabled and do_gettimeofday() is called.  Note that there is no upper
> limit to the time...
> 
> If we call gettimeoffset() after do_timer() returns (and there-by update
> the internal variables every 10ms), we should reduce the impact of this
> bug dramatically (in theory--in practice, disabling interrupts for long
> periods can also have some bad effects that this won't help, but I think
> that's another issue.)
> 
> One of the guys I'm working with did some testing on this, and he was
> seeing this problem (off by 10ms) every 5 to 10 minutes (on a modified
> ARM & kernel).  With the additional gettimeoffset() call, he no longer
> saw it (at least within ~3hrs.).
> 
> Questions, comments, etc.?

Another thought...

If we pull count_p and jiffies_p out of the various *_gettimeoffset()
functions, and added an updatetimeoffset() that only updated count_p and
jiffies_p, (and called it after every do_timer(),) we'd accomplish the
same thing, but with less overhead.

(This is based on looking at the ARM code; I haven't fully studied the
x86 & others.)

Questions, comments, etc?

Eli
-----------------------.           Rule of Accuracy: When working toward
Eli Carter             |            the solution of a problem, it always 
eli.carter(at)inet.com `------------------ helps if you know the answer.

  reply	other threads:[~2001-03-21 22:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-03 12:49 gettimeofday question Russell King
2001-03-03 16:24 ` Russell King
2001-03-19  7:33 ` Russell King
2001-03-19 11:39   ` Jamie Lokier
2001-03-19 18:26     ` Eli Carter
2001-03-19 19:06       ` Russell King
2001-03-19 19:49         ` Eli Carter
2001-03-19 21:34           ` Russell King
2001-03-19 22:54             ` Eli Carter
2001-03-19 23:44               ` Russell King
2001-03-20 15:27                 ` Eli Carter
2001-03-21 22:14             ` Eli Carter
2001-03-21 22:27               ` Eli Carter [this message]
2001-03-21 23:10                 ` Eli Carter
2001-03-21 23:27               ` Question on binutils release to use Anthony Barbachan

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=3AB92AC1.DF054E2E@inet.com \
    --to=eli.carter@inet.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lk@tantalophile.demon.co.uk \
    --cc=rmk@arm.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.