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?
Jan
