TLB flushes causing jitter on an isolated CPU — N100 / PREEMPT_RT

Hi everyone,

I’m investigating occasional 10–20 µs jitter in a custom Qt/IgH EtherCAT application, and would appreciate advice from LinuxCNC users.

Setup:
- Intel N100, Debian 13, PREEMPT_RT 6.12.107.
- 250 µs / 4 kHz cycle.
- RT thread on CPU3, SCHED_FIFO 80, nohz_full=3.
- GUI/rendering/database threads on CPUs 0–2.
- Memory locked, SAGV disabled; CPU3 fixed at 800 MHz.

All application threads currently share one process/address space.

Tracing shows Qt mprotect() and Mesa munmap() activity followed by TLB flushes on CPU3. Two +11 µs cycle-interval spikes aligned with these events. SQLite shared-memory file writeback also triggered TLB flushing, although I have not matched that to a jitter spike.

The largest untraced peak was +17 µs, so I am not claiming TLB explains every spike.

Would moving the RT loop into a separate process, communicating through preallocated fixed-size shared memory, be the recommended approach?

Has anyone measured similar interference or successfully reduced it? Are there relevant LinuxCNC implementation examples or other measurements you would suggest?

Yes, two processes should help and that is what Linuxcnc does. RT with access to ethercat master in one process, and GUI and such things in other processes, shared memory. You should be able to reach a few usecs jitter.

Measure with rtla timerlat and osnoise on CPU3 before and after. What remains isn't TLB.