On Wed, 2004-07-28 at 10:19, Jan Kiszka wrote: > Philippe Gerum wrote: > > > Hi Jan, > > > > On Tue, 2004-07-27 at 16:11, Jan Kiszka > > > >>Is there anything in xenomai which depends more on or interfers with the > >>linux kernel than the lxrt scheduler does? > > > > > > I don't think so, but I suspect that some portions of the nucleus > > (basically the timer handler and the rescheduler) are more sensitive to > > bus contention (maybe more data moved, more code to be fetched, more > > cache-unaligned stuff, I don't know yet). Add to this that the nucleus > > is a pure Adeos implementation, the hw interrupts are almost never > > masked out, but only the Xenomai domain is stalled, which leaves room > > for performance degradation if the primary IRQ handlers preempt > > otherwise interrupt-free sections and need to fiddle with the x86 > > sluggish PIC in such situation, especially when we are talking about > > 50us latencies, and not ms level ones. LXRT happens to mask the IRQs at > > hw level sometimes for internal reasons thus bypassing the pipeline for > > a limited time. Maybe instrumenting the nucleus will prove that we must > > prevent hw preemption in some rare but useful cases too. > > > > I strongly suspect that your optimistic irq locking is a bit too > optimistic ;). Actually, I cannot imagine a hardware where the WCET of > an cli/sti is greater or, at least, equal than the WCET of an even > rather short irq handler. Prove me wrong, but I think this mechanism is > not that good for a real-time system - it's a more GPOS optimisation, > isn't it? >
I'm afraid that you have already been proven wrong by the latency figures obtained with the kernel-based schedulers of RTAI/Adeos since 24.1.11. Comparing durations of cli/sti wrt primary handlers is looking at the wrong side of the problem; our problem is determinism, and as much as we can stay inside defined and acceptable time bounds, order priorities for multiple activity levels and not explode into flames when one happens to run our code on a different hw than we used to develop on, I'll be fairly happy with this approach of real-time. In this respect, 20us less or more latency where such value is almost equal to the cache uncertainty does not seem a major criterion for qualifying something as good or bad. Real-time wise, I'm an old cranky meatball: I first care of having time bounded code paths, then I work for reducing their duration; and never the other way around. > Jan -- Philippe.
