Re: [PATCH] dynamic tick patch

[George Anzinger]

Tony Lindgren wrote:
> * George Anzinger <george@xxxxxxxxxx> [050119 16:25]:
>
> > Tony Lindgren wrote:
> >
> > > * George Anzinger <george@xxxxxxxxxx> [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.
> > >
> > > 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.

This code on on sourceforge if you want a closer look...
> 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.

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.

--
George Anzinger   george@xxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/