> "more preemptive" ok but how does this bound latencies and timing jitter from event to handling? Linux RT is basically just the preempt_rt patches. In the n

> "more preemptive" ok but how does this bound latencies and timing jitter from event to handling? Linux RT is basically just the preempt_rt patches. In the normal linux kernel side, many (all?) kthreads can't be interrupted. This prevents the kernel from handling the interrupts from io in a bound time since it has to wait for a kthread to yield. The preempt_rt patches enable preempting kthreads. > E.g. I need to run a task at exactly every 100us, or within 10us of a gpio event, or ... Allowing preempting kthreads enables the kernel scheduler to run more deterministically and not be blocked by kthreads doing things. This allows the kernel to ensure a gpio task gets serviced by a given deadline. There's still spinlocks and critical sections which can block preemption, but they're minimized. Linux rt provides a "execute my thread by a deadline option". > It's less likely, but zero guarantees and no possibility of doing any sort of worst case determination. That's not "Real Time" that's just better scheduling. Hate to tell you, but thats every RTOS. The only one I know of that has a provable bounded scheduler is SeL4. IMHO, thats cool. But FreeRTOS, Zephyr? Nope same thing the Linux preempt_rt patches do. Now its smaller and easier to ensure the system isn't overloaded, less kthreads to review for critical sections, etc.