George Anzinger wrote:
Srivatsa Vaddagiri wrote:
On Tue, Aug 09, 2005 at 12:36:58PM -0700, George Anzinger wrote:
IMNOHO, this is the ONLY way to keep proper time. As soon as you
reprogram the PIT you have lost track of the time.
George,
Can't TSC (or equivalent) serve as a backup while PIT is disabled,
especially considering that we disable PIT only for short duration in
practice (few seconds maybe) _and_ that we don't have HRT support yet?
I think it really depends on what you want. If you really want to keep
good time, the only rock in town is the one connected to the PIT (and
the pmtimer). The problem is, if you want the jiffie edge to be stable,
there is just now way to reprogram the PIT to get it back to where it was.
In an old version of HRT I did a trick of loading a short count (based
on reading the TSC or pmtimer) and then put the LATCH count on top of
it. In a correctly performing PIT, it should count down the short
count, interrupt, load the long count and continue from there. Aside
from the machines that had BAD PITs (they reset on the load instead of
the expiry of the current count) there were other problems that, in the
end, cause loss of time (too fast, too slow, take your pick). I also
found PITs that signaled that they had loaded the count (they set a
status bit) prior to actually loading it. All in all, I find the PIT is
just an ugly beast to try to program. On the other hand, if you want
regular interrupts at some fixed period, it will do this forever (give
or take a epoch or two;) with out touching anything after the initial
program set up.
In the end, I concluded that, for the community kernel, it is really
best to just interrupt the irq line and leave the PIT run. Then you use
the TSC or pmtimer to figure the gross loss of interrupts and leave the
PIT interrupt again to define the jiffie edge. If you have other, more
pressing, concerns I suppose you can program the PIT, but don't expect
your wall clock to be as stable as it is now.
What are the portability and scaling issues if it were done this way? It
clearly looks practical on x86 uni, but if we want per-CPU non-tick, I'm
less sure how it would work.
But when you go to non-x86 hardware, is there always going to be another
source of wakeup available if the PIT is blocked instead of reset? I
have to go back and look at how SPARC hardware works, I don't remember
enough to be useful.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |