Re: [PATCH] dynamic tick patch

[Tony Lindgren]

* 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?

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?

Tony
-
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/