From: George Anzinger <george@mvista.com>
To: tglx@linutronix.de
Cc: Andrea Arcangeli <andrea@suse.de>,
Tony Lindgren <tony@atomide.com>, Pavel Machek <pavel@suse.cz>,
john stultz <johnstul@us.ibm.com>,
Zwane Mwaikambo <zwane@arm.linux.org.uk>,
Con Kolivas <kernel@kolivas.org>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] dynamic tick patch
Date: Wed, 19 Jan 2005 16:39:07 -0800 [thread overview]
Message-ID: <41EEFDAB.40504@mvista.com> (raw)
In-Reply-To: <1106177171.16877.274.camel@tglx.tec.linutronix.de>
Thomas Gleixner wrote:
> On Wed, 2005-01-19 at 14:59 -0800, George Anzinger wrote:
>
>>I don't think you will ever get good time if you EVER reprogramm the PIT.
>
>
> Why not ? If you have a continous time source, which keeps track of
> "ticks" regardless the CPU state, why should PIT reprogramming be evil ?
First it takes too long. Second, you are (usually) programming it to run at
1/HZ but you do this somewhere between the ticks (and, likely you don't really
know where between them you are). This last means, on the average, that you
lose 1/2 a tick time, i.e. the tick interrupt will happen 1/2 a tick late for
each reprogramm done.
If you say, well, lets just use the TSC (or some other timer) you have the
problem that in x86 boxes those don't rely on "rocks" selected for time keeping,
so you have an inaccurate clock to this degree. Also, in the case of the TSC,
at boot time we "try" to figure out how many cycles of TSC it takes to do a PIT
cycle by "looking" as the PIT in a loop while we catch the TSC. Problem is that
the I/O sync needed to look at the PIT is several TSC cycles long and we don't
really know how close we got. Even using the max PIT time of around 50 ms the
error on my 800 MHZ PII is 10 or more TSC cycles.
At one point I tried to get the PIT to sync back up by doing a short cycle
followed by the normal cycle. I.e. I loaded the counter for the time remaining
in the jiffie, started the PIT and then loaded the 1/HZ latch count on top of
it. The spec says the new count should be loaded by the chip when the current
one expires. This sort of worked, but I still got feedback on clock drift.
Also, there are some PITs out there that don't do this correctly. And in the
load part, you have to wait for the first program to start prior to loading the
second one. This is a busy loop waiting for an I/O event, i.e. much too long.
We should also keep in mind that we really want the timer tick to happen as
close as possible to the jiffies++ as possible. Especially if we are doing high
res timers, any delay here will show up as late timers.
>
>
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
next prev parent reply other threads:[~2005-01-20 0:39 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-19 0:05 [PATCH] dynamic tick patch Tony Lindgren
2005-01-19 0:22 ` Lee Revell
2005-01-19 1:04 ` Tony Lindgren
2005-01-19 4:21 ` Benjamin Herrenschmidt
2005-01-19 5:07 ` Tony Lindgren
2005-01-19 5:21 ` Tony Lindgren
2005-01-19 5:44 ` Benjamin Herrenschmidt
2005-01-19 6:26 ` Tony Lindgren
2005-01-19 9:45 ` Pavel Machek
2005-01-19 5:28 ` Benjamin Herrenschmidt
2005-01-19 6:37 ` Tony Lindgren
2005-01-19 7:08 ` Benjamin Herrenschmidt
2005-01-19 7:31 ` Tony Lindgren
2005-01-19 14:11 ` Stephen Frost
2005-01-19 17:17 ` Tony Lindgren
[not found] ` <OFDC470564.D4624EB3-ON41256F8E.00512848-41256F8E.005428CC@de.ibm.com>
2005-01-19 17:37 ` Tony Lindgren
2005-01-19 9:43 ` Pavel Machek
2005-01-19 17:13 ` Tony Lindgren
2005-01-19 17:48 ` Andrea Arcangeli
2005-01-19 18:19 ` Tony Lindgren
2005-01-19 19:12 ` Andrea Arcangeli
2005-01-19 19:17 ` Tony Lindgren
2005-01-19 19:34 ` Tony Lindgren
2005-01-19 22:42 ` Andrea Arcangeli
2005-01-19 22:59 ` George Anzinger
2005-01-19 23:17 ` Tony Lindgren
2005-01-20 0:24 ` George Anzinger
2005-01-20 8:04 ` Tony Lindgren
2005-01-20 23:10 ` George Anzinger
2005-01-21 17:35 ` Tony Lindgren
2005-01-21 20:23 ` George Anzinger
2005-01-19 23:26 ` Thomas Gleixner
2005-01-19 23:45 ` john stultz
2005-01-20 5:56 ` Thomas Gleixner
2005-01-20 0:39 ` George Anzinger [this message]
2005-01-20 3:15 ` Valdis.Kletnieks
2005-01-19 11:36 ` Pavel Machek
2005-01-19 17:11 ` Tony Lindgren
2005-01-19 17:30 ` Arjan van de Ven
2005-01-19 17:41 ` Tony Lindgren
2005-01-19 22:06 ` Pavel Machek
2005-01-19 23:08 ` Tony Lindgren
2005-01-19 23:46 ` Pavel Machek
2005-01-19 23:53 ` Tony Lindgren
2005-01-19 23:59 ` Pavel Machek
2005-01-20 0:07 ` Tony Lindgren
2005-01-20 0:44 ` Pavel Machek
2005-01-20 0:54 ` Pavel Machek
2005-01-20 7:39 ` Tony Lindgren
2005-01-19 22:20 ` Pavel Machek
2005-01-20 4:02 ` Zwane Mwaikambo
2005-01-21 17:48 ` Tony Lindgren
2005-01-21 18:27 ` Zwane Mwaikambo
2005-01-21 18:38 ` Tony Lindgren
2005-01-21 18:54 ` Pavel Machek
2005-01-21 21:23 ` Zwane Mwaikambo
2005-01-21 21:29 ` Pavel Machek
2005-01-21 20:25 ` George Anzinger
2005-01-21 21:38 ` Zwane Mwaikambo
2005-01-22 7:24 ` George Anzinger
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=41EEFDAB.40504@mvista.com \
--to=george@mvista.com \
--cc=andrea@suse.de \
--cc=johnstul@us.ibm.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=tony@atomide.com \
--cc=zwane@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox