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

[Bill Davidsen <davidsen@tmr.com>]

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