Markus Franke wrote: > Jan Kiszka wrote: >> Of course, irqloop runs in *primary* mode to be able to handle the >> events deterministically. So it is not directly affected by CONFIG_PREEMPT. > > If I start irqloop in User-Mode, a thread is simply created via Linux > system call pthread_create() which interacts with the > xeno_irqbench-driver via ioctl(). But then I don't understand why > irqloop is running in Primary (Xenomai) Mode? Because of the interaction > with the RTDM-based driver? > I am just wondering because I can't see something like rt_task_create().
<see Dmitry's reply> > >> Yes, if you have an RT thread that issues syscalls and wishes to have >> them handled as fast as possible, CONFIG_PREEMPT should be enabled (and >> CONFIG_XENO_OPT_RPIDISABLE should remain off, maybe you even want to >> consider CONFIG_XENO_OPT_ISHIELD then). Such RT application designs are >> tricky to get correct and deterministic, so it's often better to not >> rely on these properties and rather seek a clear separation of pure RT >> threads on the one side and Linux syscall issuing non-RT or RT >> borderline threads (low-prio RT threads that are being switched back and >> forth between primary and secondary mode) on the other. > > Ok I understand. So native kernel preemption should only provide better > results if you have realtime-threads issuing linux systemcalls which is > not really convenient. It is for sure convenient. But it doesn't take the burden from you to understand what is happening underneath. That's my point. > >> Shadowed by CONFIG_DEBUG=n likely. > > probably by CONFIG_DEBUG_KERNEL=n Yep. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
