Speaker
Description
RISC-V Linux TLB flushing has several runtime paths. A flush may be local to the current hart, may use SBI remote fence support, or may fall back to Linux IPIs. The kernel also makes range-versus-full decisions, performs ASID-aware flushing, and carries different flush strides for normal and huge-page ranges. These decisions can matter when debugging correctness issues, performance anomalies, and SMP scalability problems, but they are not currently visible in a compact RISC-V-specific form.
This talk presents a small RFC tracepoint patch that makes the Linux-side RISC-V TLB flush decision visible. The proposed tracepoint records the requested flush range, stride, ASID, target CPU count, flush type, threshold decision, and selected transport path: local, SBI remote fence, or IPI fallback.
The goal is intentionally narrow. This is not a hardware TLB profiler and not a complete MM observability framework. It focuses on one practical question: when Linux decides to invalidate RISC-V address translations, can a developer easily see which path was selected and why?
The talk will walk through the relevant RISC-V kernel TLB-flush path, explain what existing tracing can and cannot show, and demonstrate the proposed tracepoint using QEMU and one real RISC-V board. A small multi-threaded mmap() / mprotect() / munmap() workload will be used to trigger local and remote flushes and to show range-size effects around the current threshold logic.
Attendees will leave with a concrete understanding of how RISC-V TLB flush decisions are made in Linux, how they can be observed today, what a minimal tracepoint adds, and what trade-offs should be considered before adding architecture-specific observability to hot MM paths.
Comments:
This topic is primarily intended for the RISC-V MC because it focuses on arch/riscv MM/TLB behavior, including local flushes, SBI remote fences, and IPI fallback paths. If the organizers think the tracing or MM angle is a better fit elsewhere, it could also be considered for the Tracing MC or Kernel Memory Management MC.
I previously presented in the FOSDEM 2026 Kernel devroom with a practical talk on reproducing a Linux kernel bug using virtme-ng. This LPC proposal is a different topic, but it follows the same practical style: a small kernel RFC patch, reproducible QEMU testing, and validation on real RISC-V hardware where possible.