* Thomas Gleixner <[email protected]> [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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
