Re: [PATCH] dynamic tick patch

[George Anzinger]

Tony Lindgren wrote:
> * George Anzinger <george@xxxxxxxxxx> [050120 15:10]:
>
> > 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.
>
>
> 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@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/