rtla: what is next?
summary
rtla provides a usable interface for kernel latency tracers and already ships a timerlat tracer that measures IRQ and thread latency (similar to cyclictest) and writes text traces; it reliably finds OS-caused latencies but overflows the ftrace buffer on very large systems (>100 CPUs with ~100 μs periods) because events are ftrace-only not tracepoints so in-kernel histograms and triggers are unavailable. Planned work: integrate hardware latency tracer (SMI/hardware noise) with timerlat to correlate OS vs hardware delays, add support for trace.data files to merge multiple CPU traces, and fold the experimental rtsl scheduler checker into timerlat for automated analysis.
AI-written summary · about
related talks
51mRTLA Timerlat - the next step in scheduling latency analysis
21mRTLA Requests and TODOs
50mrtla timerlat: Debugging Real-Time Linux Scheduling Latency
47mReal-Time Linux: What Is Next?
26mReal-time Linux: what is next?
40mRT Linux in Safety-Critical Systems: The Potential and the Challenges
59mProposing a new tracer to monitor RT task behavior
26mTuning Real-Time Linux for ARM SoCs