Messages in this thread | | | Date | Wed, 15 Dec 2004 10:32:46 +0100 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0 |
| |
* Paul Davis <paul@linuxaudiosystems.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |