From: George Anzinger <george@mvista.com>
To: Joe Korty <joe.korty@ccur.com>
Cc: Peter Chubb <peter@chubb.wattle.id.au>,
root@chaos.analogic.com, Stephen Hemminger <shemminger@osdl.org>,
Gabriel Paubert <paubert@iram.es>,
john stultz <johnstul@us.ibm.com>,
Linus Torvalds <torvalds@osdl.org>,
lkml <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC] possible erronous use of tick_usec in do_gettimeofday
Date: Tue, 25 Nov 2003 11:57:55 -0800 [thread overview]
Message-ID: <3FC3B443.2060804@mvista.com> (raw)
In-Reply-To: <20031125164237.GA15498@rudolph.ccur.com>
Joe Korty wrote:
> test10's version of do_gettimeofday is using tick_usec which is
> defined in terms of USER_HZ not HZ.
>
> Against 2.6.0-test10-bk1. Compiled, not tested, for comment only.
We still have the problem that we are doing this calculation in usecs while the
wall clock uses nsecs. This would be fine if there were an even number of usecs
in tick_nsec, but in fact it is somewhat less than (USEC_PER_SEC / HZ). This
means that this correction (if we are behind by 7 or more ticks) will push the
clock past current time. Here are the numbers:
tick_nsec =999849 or 1ms less 151 ns. So if we are behind 7 or more ticks we
will report the time out 1 us too high. (7 * 151 = 1057 or 1.057 usec).
Question is, do we care? Will we ever be 7ms late in updating the wall clock?
As I recall, the wall clock is updated in the interrupt handler for the tick so,
to be this late, we would need to suffer a long interrupt hold off AND the tick
recovery code would need to have done its thing. But this whole time is covered
by a write_seqlock on xtime_lock, so how can this even happen? Seems like it is
only possible when we are locked and we then throw the whole thing away.
A test I would like to see is to put this in the code AFTER the read unlock:
if (lost )
printk("Lost is %d\n", lost);
(need to pull " unsigned long lost;" out of the do{}while loop to do this)
In short, I think we are beating a dead issue.
-g
>
> Joe
>
> --- base/arch/i386/kernel/time.c 2003-11-23 20:31:55.000000000 -0500
> +++ new/arch/i386/kernel/time.c 2003-11-25 11:22:38.000000000 -0500
> @@ -94,7 +94,7 @@
> {
> unsigned long seq;
> unsigned long usec, sec;
> - unsigned long max_ntp_tick = tick_usec - tickadj;
> + unsigned long max_ntp_tick;
>
> do {
> unsigned long lost;
> @@ -110,13 +110,14 @@
> * Better to lose some accuracy than have time go backwards..
> */
> if (unlikely(time_adjust < 0)) {
> + max_ntp_tick = (USEC_PER_SEC / HZ) - tickadj;
> usec = min(usec, max_ntp_tick);
>
> if (lost)
> usec += lost * max_ntp_tick;
> }
> else if (unlikely(lost))
> - usec += lost * tick_usec;
> + usec += lost * (USEC_PER_SEC / HZ);
>
> sec = xtime.tv_sec;
> usec += (xtime.tv_nsec / 1000);
>
>
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
next prev parent reply other threads:[~2003-11-25 19:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-27 23:44 gettimeofday resolution seriously degraded in test9 Joe Korty
2003-10-28 0:15 ` Stephen Hemminger
2003-10-28 0:29 ` john stultz
2003-10-28 1:17 ` Stephen Hemminger
2003-10-28 11:55 ` Gabriel Paubert
2003-10-28 18:21 ` Stephen Hemminger
2003-10-29 10:07 ` Gabriel Paubert
2003-10-29 19:38 ` Stephen Hemminger
2003-10-29 22:50 ` Peter Chubb
2003-10-30 21:33 ` George Anzinger
2003-10-30 21:52 ` Richard B. Johnson
2003-10-30 22:50 ` Chris Friesen
2003-10-30 23:15 ` Peter Chubb
2003-10-30 23:47 ` George Anzinger
2003-11-25 16:42 ` [RFC] possible erronous use of tick_usec in do_gettimeofday Joe Korty
2003-11-25 17:13 ` Stephen Hemminger
2003-11-25 19:57 ` George Anzinger [this message]
2003-11-25 21:12 ` Joe Korty
2003-11-25 23:26 ` George Anzinger
2003-10-30 23:27 ` gettimeofday resolution seriously degraded in test9 George Anzinger
2003-10-30 10:39 ` Gabriel Paubert
[not found] <Lq47.3Go.11@gated-at.bofh.it>
[not found] ` <LqGL.4zF.11@gated-at.bofh.it>
[not found] ` <LAPN.1dU.11@gated-at.bofh.it>
[not found] ` <LGLz.1h2.5@gated-at.bofh.it>
[not found] ` <LVAR.4Mb.3@gated-at.bofh.it>
[not found] ` <M4uv.bw.5@gated-at.bofh.it>
[not found] ` <M7sx.4et.13@gated-at.bofh.it>
[not found] ` <MsGE.8cN.19@gated-at.bofh.it>
[not found] ` <MsZZ.c3.5@gated-at.bofh.it>
[not found] ` <Mufp.1YL.15@gated-at.bofh.it>
[not found] ` <VOyG.w9.35@gated-at.bofh.it>
2003-11-28 1:29 ` [RFC] possible erronous use of tick_usec in do_gettimeofday Andi Kleen
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=3FC3B443.2060804@mvista.com \
--to=george@mvista.com \
--cc=akpm@osdl.org \
--cc=joe.korty@ccur.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paubert@iram.es \
--cc=peter@chubb.wattle.id.au \
--cc=root@chaos.analogic.com \
--cc=shemminger@osdl.org \
--cc=torvalds@osdl.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