Re: [Xenomai-help] CONFIG_PREEMPT & irqbench

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]