Philippe Gerum wrote:
So, basically, in your views, any attempt to virtualize the IRQ handling
is doomed for real-time? How does RTLinux, RTAI over RTHAL and a bunch
of other Windows-based stuff work, then? ;o)
For obvious reasons not for the non-real-time part, but the real-time
part should have the best, i.e. fastest, irq management which is
available on a specific platform.
The fact is that Stodolsky's proposal can be used the same way for
different purposes, that's all. If this optimizes the average case
without wrecking the worst case one, but additionally allows to defer
the interrupts for whatever purpose, that's fine. Indeed.
Agree - if your conditions are fulfilled in practice ;)
Adeos is virtualizing the IRQ flow too, what's new with the Adeos model
is to use this feature to prioritize the incoming events among any
number of domains according to a pipeline abstraction, and not just to a
single most prioritary domain. So the additional cost compared to the
old-fashioned way is basically defined by the cost of transitioning
between multiple domains.
I'm aware that the irq virtualisation for high-priority (real-time)
domains comes from the basic adeos concept. But even if it is nice in
the model, we should also consider its effects in reality.
Ok, this approach is as deterministic as the classic cli/sti: The worst
case scenario is now critical section length + deferred irq call(s???).
But this variant is also in no way MORE deterministic than the classic one.
Who--said--that??? The purpose of Adeos has never been, is not and will
never be to pretend working faster than the hardware does! :o))
Is this a point where the adeos concept has a higher priority for you
than the performance? Please don't take it as a criticism, I'm only
trying to understand the motivation and goal.
Come on... what's important is that it brings a common low level
architecture for supporting event prioritization, that improves
portability, provides a uniform interface and _behaviour_ among
different archs, and provides performances that are comparable to the
ones of the old-fashioned stuff, where you are basically immediately fed
by the interrupt vector.
Everything has a cost: if it's acceptable performance-wise like you seem
to find it out by yourself with your test on a P1, then you will likely
accept this cost to get back a much larger benefit.
Keep in mind that you could not have Marc's stuff work on Xenomai
without Adeos; the 50us more you pay now should be reduced to something
around 20us compared to LXRT by a careful investigation and proper
optimization; but even if you would have to live with 20us more
_bounded_ latency, I don't think this would prevent you from having a
properly working application, unless your constraints are so tight that
this figure would not fit. But in the latter case, x86, and its
terminally ill architecture wrt to very high determinism, is definitely
not the arch you would have chosen in the first place, I guess.
I can, indeed, live with 20 us more latency (but not with up to 100 us
as we measured on some other box). The point are also not that
additional 10 or maybe 20 us which are probably caused by the irq
virtualisation for the real-time core. It's more that I'm afraid, if we
are to slackly in this regard, we may have problems reducing the total
jitter to a more acceptable level (when thinking about replacing RTAI
with xenomai+skin in the future).
I just did a quick experiment on vesuvio with Marc's skin on a PI
266-MMX (text-only, no disk access, only ping -f and some user mode
load): replacing rtai_local_irq_save/rtai_local_irq_restore with
rtai_hw_lock/rtai_hw_unlock improved the situation a bit. The maximum
jitter decreased from about 85 to 75 us. So, it seems that this
mechanism has an effect, but it is also not the dominating one. As you
said, the cache locality of code and data is likely a bit worse with
xenomai+skin compared to lxrt. I hope this is not too much due to the
layer concept.
A layered approach is not bad because of the layering per se, but
because the abstraction levels are not properly defined. So the real
question is: does Xenomai has those right? I intuitively think so, but
the only thing that can solve the matter here is bringing facts, and I
intend to do so when I can pour more time into fusion, i.e. when I won't
be able to help more on vesuvio.
I know your time is limited and I appreciate your work very much. It's
just that I wanted to hear: Yes we can reduce these numbers to a
well-known level - also on low-end machines. I need a perspective so
that I can sleep easily :)
Jan
