Wow! Thanks, Bruce, Fredrik, and everyone, for all this useful info! > > I'm running a 10us control loop by (under vxWorks) setting one thread's > > priority to max and not yielding ever > > <[email protected]> wrote: > You are looking for kernel functionality that doesn't exist yet. In > any SMP system there are sources of cross cpu interference that can't > be removed, if you do, the global state machines of the kernel will > break and the system will eventually come to a halt. > > That's the mainline/scalable point of view, there are plenty of "custom" > and one off solutions to the problem, such as hotplugging the cpu out > of the system and running in an AMP configuration where a bare metal, > or RTOS can monopolize a CPU since the global state machines don't > interfere. These have their advantages and disadvantages, but if you > are coming from an existing RTOS application, they might be the > closest options to get you the performance you are looking for.
An AMP configuration does seem like the closest thing to what the RTOS gave me. Do you have more info about that? Specifically, I see that I can remove a core from the scheduler ($ echo 0 > /sys/devices/system/cpu/<core number>/online), but how can I make my run my code on that core? Do I get the code running on that core first and then remove the core, or vice-versa, or some other concept? I do PCIe reads/writes - are those affected? I use atomic read-write-modify locks for critical sections - will those still function correctly (I can't imagine they would break, but I thought I'd ask)? > > So maybe disabling RT throttling is all I need to do, maybe some other > > approach is needed. Hopefully someone will know more than I do. > > > <[email protected]> wrote: > The RT-throttling can be disabled with: > > echo -1 >/proc/sys/kernel/sched_rt_runtime_us > echo -1 >/proc/sys/kernel/sched_rt_period_us > > But as mentioned in the other answers things like the system tick, ipi:s > etc. will interfere. But significantly less then the rt-throttling :) Thanks, Fredrick! I will try this. Dave Mulder _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
