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 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
