Markus Franke wrote: > Jan Kiszka wrote: >> CONFIG_PREEMPT helps here to reduce the worst case (PREEMPT_RT even >> more, but it currently collides with patching the kernel). On the other >> hand, it increases the overhead for your Linux subsystem (check with >> lmbench e.g.). Still, depending on what you need, you are able to tune >> Linux'es own preemption model freely when using Xenomai and I-pipe. > > So at the moment it is not possible to use PREEMPT_RT-Patch and > Xenomai/Adeos together?
[adding the list to CC again] If you browse the Xenomai and I-pipe code, you will find some hints that this once worked and Xenomai is basically prepared for it. To combine both patches today, we would have to adopt I-pipe not only to genirq (which is almost done for 2.6.19), but also to the full hrtimer+dyntick (clocksource/clockevent) infrastructure. Moreover, quite some time has passed since the last I-pipe/-rt combo patch, and both PREEMPT_RT and I-pipe changed since then. Do there might be more subtle issues hidden for a combination. Still, this is technically feasible and will come over the time when PREEMPT_RT continues to "leak" into mainline. The question is if using the result (CONFIG_IPIPE+CONFIG_PREEMPT_RT) is also what you want: Combining both strategies also means adding overhead of I-pipe's paravirtualisations and PREEMPT_RT's IRQ threading & sleeping locks. The future development, Xenomai 3, therefore aims at rebasing the nucleus over the -rt patch while keeping its ability to run alternatively over vanilla + I-pipe. Depending on your requirements - full system preemptibility vs. focused RT-subsystem - you will then be able to switch the model without application or driver rewrites. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
