On Tue, Aug 11, 2020 at 7:43 AM Michel Macena Oliveira <michel@xxxxxxxxxxxxxxxxxxxx> wrote: > > Austin thanks for the Idea, those tests will give more reliable results. > Itai thanks for the idea, I will search more about ftrace. > > Another newbie question, when I put a read or write call inside a > thread with real time priority, I can say that the call is real time > scheduled or should I code in a different way > to "make it" real time? I mean, if just the fact that a function is > inside the RT thread with high priority is enough to say it is real > time. I am asking this because I'm > still learning how the real time context fits into the Preempt RT > kernel concept. In principle, there's nothing special you need to do from the user space side. In practice, every driver is special in it's own way. There are threaded IRQs associated with the critical path from IO to you that you may want to re-prioritize. You'll find bugs in other drivers where there are work-queues in the middle. The list goes on. I've found that the best thing to do is exactly what you are doing, setup a benchmark which actually lets you measure the latency and jitter, see how well it is performing, and start tracing to figure out if something is going wrong in the critical path. I've found tracing the scheduler, irq, and workqueue events to be quite effective at figuring what is going on. Austin
