Re: [PATCH] dynamic tick patch

[George Anzinger <george@mvista.com>]

Tony Lindgren wrote:
> * George Anzinger <george@mvista.com> [050120 15:10]:
> 
>>Tony Lindgren wrote:
>>
>>>* George Anzinger <george@mvista.com> [050119 16:25]:
>>>
>>>
>>>>Tony Lindgren wrote:
>>>>
>>>>
>>>>>* George Anzinger <george@mvista.com> [050119 15:00]:
>>>>>
>>>>>
>>>>>
>>>>>>I don't think you will ever get good time if you EVER reprogramm the 
>>>>>>PIT. That is why the VST patch on sourceforge does NOT touch the PIT, 
>>>>>>it only turns off the interrupt by interrupting the interrupt path (not 
>>>>>>changing the PIT).  This allows the PIT to be the "gold standard" in 
>>>>>>time that it is designed to be.  The wake up interrupt, then needs to 
>>>>>>come from an independent timer.  My patch requires a local APIC for 
>>>>>>this.  Patch is available at 
>>>>>>http://sourceforge.net/projects/high-res-timers/
>>>>>
>>>>>
>>>>>Well on my test systems I have pretty good accurate time. But I agree,
>>>>>PIT is not the best option for interrupt. It should be possible to use
>>>>>other interrupt sources as well.
> 
> 
> But then again reprogramming PIT in my patch should not be that bad,
> as it's not done under load.
> 
> 
>>>>>It should not matter where the timer interrupt comes from, as long as 
>>>>>it comes when programmed. Updating time should be separate from timer
>>>>>interrupts. Currently we have a problem where time is tied to the
>>>>>timer interrupt.
>>>>
>>>>In the HRT code time is most correctly stated as wall_time + 
>>>>get_arch_cycles_since(wall_jiffies) (plus conversion or two:)).  This is 
>>>>some what removed from the tick interrupt, but is resynced to that 
>>>>interrupt more or less each interrupt.
>>>
>>>
>>>That sounds very accurate :)
>>>
>>>
>>>
>>>>A second issue is trying to get the jiffies update as close to the run of 
>>>>the timer list as possible.  Without this we have no hope of high res 
>>>>timers.
>>>
>>>
>>>OK. But if the timer interrupt is separated from updating the time,
>>>the next timer interrupt should be programmable to happen exactly
>>>when a HRT timer needs it, right?
>>
>>First, HRT uses a two phase system of timing.  The first phase is the 
>>normal timer list expires the timer.  The timer is then handed to the high 
>>res code which keeps a list of timers that are to expire prior to the next 
>>jiffie.  An interrupt is scheduled to make this happen.  Depending on the 
>>hardware available, this can come from the same timer or a different timer. 
>>For example on x86 systems with a local apic we use the apic timer to 
>>generate this interrupt.  It triggers either a tasklet for UP or SMP with 
>>out per cpu timers or a soft irq for SMP systems with per cpu timers.
>>
>>What this means is that, for timers near but just after a jiffie, the 
>>run_timer list being late can make the HR timer late.
> 
> 
> Thanks for explaining that. So basically catching up with jiffies after
> skipping ticks could easily delay the HRT timer.

Any due in the "skipped time" would be late, as would any normal timers due 
during that time.
> 
> If jiffies was calculated from hw timer, updating time after skipping
> jiffies would be fast, and then this problem would go away, right?

No, you are still pulling the timers out of the timer list long after they 
should have expired.
> 
> 
>>This code on on sourceforge if you want a closer look...
> 
> 
> I'll take a look at it.
> 
> 
>>>Hmm, how about using a pool of programmable timers available on the 
>>>system for the timer interrupts and HRT? Or is one interrupt source
>>>always enough?
>>
>>Hardware heaven :), but no thanks.  A reliable tick generator for the 
>>jiffies timer and one additional timer (or one per cpu) works well in the 
>>x86.
>>
>>If you have something like the PPC where you can mess with the timer with 
>>out loosing time, that works well also.  The correct formulation would be a 
>>"clock" that can be read quickly and a timer tied to the same "rock" that 
>>uses the same count units as the clock.  PARISC has a counter that just 
>>counts and a compare register.  When they are equal an interrupt is 
>>generated.  That is a nice set up.
> 
> 
> Yes, many ARMs have this setup as well.
> 
> 
>>Now the X86 is bad and has little hope of being fixed for these reasons:
>>a.) the TSC is fast and easy to read but its not clocked at any given 
>>frequency and, on some platforms, it changes without notifying the software.
>>b.) the PIT and the PMTIMER are both in I/O space and so take forever to 
>>access.
>>c.) All three of these use different units (but at least the PMTIMER is 
>>(supposed to be) related to the PIT clock.
>>d.) the HPET, again is in I/O space.  I suspect that it uses a reasonable 
>>"rock" but, as I understand it, it knocks out the PIT and, of course it 
>>uses units unrelated to all the others.
> 
> 
> The timers on x86 are quite messy...

AMEN!
> 
> Tony
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/