Re: + fix-next_timer_interrupt-for-hrtimer.patch added to -mm tree

[Tony Lindgren <tony@atomide.com>]

* Thomas Gleixner <tglx@linutronix.de> [060228 02:05]:
> Tony,
> 
> On Tue, 2006-02-28 at 01:51 -0800, Tony Lindgren wrote:
> > Cool, after a quick test seems to work OK here. Any ideas how to fix the
> > locking problem above?
> > 
> > Maybe one option would be to just reprogram the hardware timer when a
> > new hrtimer is added. That would then allow subjiffie timers too.

Actually to me it looks like the read lock should do just fine on ARM,
as timer_dyn_reprogram() is called from idle loop with interrupts
disabled.
 
> You might have a look into the high resolution timer patches on top of
> hrtimers at http://www.tglx.de/projects/hrtimers

I'll take a look at those once I have some more time...
 
> The clockevents abstraction layer is a quick attempt to generalize the
> problem around event generation. I'm stuck in some other work right now,
> but I'm going to rework this layer soon. IMO John Stultz GTOD patches
> and the generalization of clock events will be a sane base for high
> resolution timers and dynamic ticks.

Yeah. And then we also need to change next_timer_interrupt() return
nanoseconds.

Regards,

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