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(). > 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. > Shadowed by CONFIG_DEBUG=n likely. probably by CONFIG_DEBUG_KERNEL=n _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
