Re: [PATCH v2] riscv: mm: Trace TLB flush path selection

[Jisheng Zhang <jszhang@kernel.org>]

On Thu, Oct 15, 2026 at 07:33:13AM +0800, Jisheng Zhang wrote:
> On Wed, Oct 14, 2026 at 05:58:42PM +0200, Roman Storozhenko wrote:
> > Hi Jisheng,
> > 
> > Thanks for the clarification.
> > 
> > Since Radim's tracepoint code-generation results are now part of this
> > discussion, I've added him to Cc in case I misinterpret any aspect of
> > that issue.
> > 
> > I agree with you on one point regarding the compiler overhead. Since
> > the kernel supports older GCC versions, we have to take the code
> > generated by those supported compilers into account today. So
> > describing the issue simply as temporary was too strong.
> > 
> > However, I think there are two separate questions here: whether the
> > event exposes useful information, and whether the disabled-path cost
> > of its current implementation is acceptable.
> > 
> > Regarding kprobes, most of the raw fields in this event are indeed
> > already arguments of `__flush_tlb_range()`. My point is not that these
> > values are impossible to obtain dynamically.
> > 
> > Kprobes can be used to observe a very large part of the kernel. If the
> > ability to reconstruct an event with kprobes were by itself sufficient
> > reason not to add a tracepoint, the same reasoning would apply to many
> > existing tracepoints.
> > 
> > The distinction I see here is between observing implementation details
> > and exposing the semantic event directly.
> > 
> > For this case, the interesting information is not only `start`,
> > `size`, `stride`, `cmask`, etc., but their correlation with the path
> > Linux selected for that particular request:
> > 
> >         local
> >         SBI RFENCE
> >         cross-CPU call
> > 
> > Calculating the local case from `cmask` may be simple with the current
> > implementation, but the tracing program still has to reproduce
> > knowledge of the selection logic. Likewise, observing downstream
> > functions ties the tracing program to the current call graph.
> > 
> > I also don't think `/proc/interrupts` provides equivalent information here.
> > 
> > The RISC-V IPI statistics are aggregate counters. In particular, Linux
> > accounts `IPI_CALL_FUNC` as "Function call interrupts", while SBI
> > RFENCE is handled below Linux by firmware; for example, OpenSBI
> > implements the remote TLB operation using its own `IPI_TLB` event.
> 
> I think you misunderstood something. A riscv platform uses either
> SBI RFENCE or IPI for tlb shootdown, and won't change. So you can
> know whether the system is SBI RFENCE powered or IPI powered by
> cat /proc/interrupts. It's much simpler.

Aha, I missed aclint sswi case, if sswi, no explict /proc/interrupts
difference between sswi and traditonal plic. However, whether TLB is
powered by SBI RFENCE or IPI can still be known by checking
"providing IPIs using SBI IPI extension" in dmesg.