Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0

[Ingo Molnar]

* Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote:

> the latter. to send MIDI Clock or MIDI Timecode requires an interrupt
> source that is not locked to jiffie-ish intervals or power-of-2
> related intervals. For example, MTC requires sending 2 bytes roughly
> every 0.8msec. Sending them every msec isn't good enough, in general.

yeah, i can understand that - 20% slower music is bad, even to kernel
hackers ;-)

> my understanding of the HRT patch is that it allows the timer to be
> reprogrammed to elapse with nanosecond resolution. i don't understand
> why linus has been so reluctant to move linux in this direction, other
> than it being hard to fit into the existing fixed interval timer
> framework.

i dont think there's any particular type of feeling from Linus towards
HRT - it's always the quality of the patch (and the underlying
fundamental issues) that controls, plus 'demand'. So integrating this
stuff is not a matter of will, it's a matter of having good enough code.

the current 'fixed interval timer framework' is one reason that makes
Linux scale so well on big networked boxes, which can easily have
millions of timers running (per CPU). Sub-jiffy solutions i've seen so
far tended to concentrate on making sub-jiffies work, while keeping
fixed interval timers only as a side-effect. That's not how usage
demands it - right now fixed interval timers are king in terms of usage
(and will be king even if we had HRT integrated), so subjiffy timers
must be very precisely engineered to not hurt fixed interval timers.
Plus if we touch the timer code then maybe it could be made more
deterministic (cascading isnt quite deterministic right now) - which
further complicates things. It's not a simple and clear-cut task for
sure.

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