Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 5

Bill Davidsen
2005-08-11T21:31:12Z

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me