lkml.org 
[lkml]   [2005]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] dynamic tick patch
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/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.058 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site