Jan Kiszka wrote:
Nicholas Mc Guire wrote:
I know that people want to move to user-space - but what is the
advantage
over RT-preempt then if you use the dynamic tick patch (scheduled to go
mainline in 2.6.21 BTW) ?
So far, determinism (both /wrt mainline and latest -rt).
BTW, kernel space real time is specifically no longer recommendable for
commercial projects that have to worry about the (likely non-GPL)
license of their application code. And then there are those countless
technical advantages that speed up the development process of user space
apps.
well I don't see that advantage at this point - determinism seems to be
in the same range as you get on ADEOS based systems. That there is a
move towards user-space is clear.
Yeah, it /seems/...
my suspicion is that there is too much work being done on fast-hot
CPUs
and the low-end is being neglected - which is bad as the numbers you
post here for ADEOS are numbers reachable with mainstream preemptive
kernel by now as well (off course not on the low end systems though).
That's scenario-dependent. Simple setups like a plain timed task can
reach the dimension of I-pipe-based Xenomai, but more complex scenarios
suffer from the exploding complexity in mainstream Linux, even with
-rt.
Just think of "simple" mutexes realised via futexes.
do you have some code samples with numbers ? I would be very
interested in
a demo that shows this problem - I was not able to really find a smoking
gun with RT-preempt and dynamic ticks (2.6.17.2).
I can't help with demo code, but I can name a few conceptual issues:
o Futexes may require to allocate memory when suspending on a contented
lock (refill_pi_state_cache)
o Futexes depend on mmap_sem
ok - thats a nice one
o Preemptible RCU read-sides can either lead to OOM or require
intrusive read-side priority boosting (see Paul McKenney's LWN
article)
o Excessive lock nesting depths in critical code paths makes it hard to
predict worst-case behaviour (or to verify that measurements actually
already triggered them)
well thats true for ADEOS/RTAI/RTLinux as well - we are also only
black-box testing the RT-kernel - there currently is absolutley NO
prof for worst-case timing in any of the flavours of RT-Linux.
Nope, it isn't. There are neither sleeping not spinning lock nesting
depths of that kind in Xenomai or Adeos/I-pipe (or older RT extensions,
AFAIK) - ok, except for one spot in a driver we have scheduled for
re-design already.
o Any nanosleep&friends-using Linux process can schedule hrtimers at
arbitrary dates, requiring to have a pretty close look at the
(worst-case) timer usage pattern of the _whole_ system, not only the
SCHED_FIFO/RR part
true - but resource overload hits all flavours - and the splitt of
timers and timeouts in 2.6.18++ does reduce the risk clearly.
Compared to making all Linux timers hrtimers? Yes, for sure. But that
would be an insane idea anyway, just considering all the network-related
timers.
That's what I can tell from the heart. But one would have to analyse the
code more thoroughly I guess.
thanks for the imput - at the embedded world Thomas Gleixner
demonstrated a simple control system that could sustain sub 10us
scheduling jitter under load based on the latest rt-preempt + a bit
of tuning I guess (actually don't know).
Without knowing the test (Wolfgang, did you see it?), I would guess the
setup as follows: dual-core GHz Pentium, isolated core for the timed
task, no peripheral interaction, no synchronisation means, likely even
no further syscalls except for the sleep service. Surely a progress over
plain Linux, but that one's only useful for very specific scenarios.
No, I have not seen it. But I believe, that with careful hardware
selection it's possible to achieve that. On high-end systems the latency
is dominate by hardware. On low-end systems code size matters. So far I
have not seen any serious comparison for low-end Linux systems and -rt
does not work yet on PowerPC (the high-res support is still missing).
No one claims -rt is not useful or too limited. Each approach has its
preferred application domain. Knowing strength and weaknesses of both is
required here. And providing the user the choice (like Xenomai 3 will).
The essence for me is that with
the work in 2.6.X I don't see the big performance jump provided by teh
hard-RT variants around - especially with respect to guaranteed worst
case (and not only "black-box" results).
Could it be a bit too enthusiastic to base such an assessment on a
corner-case demonstration?
Jan
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
