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

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:

quoted

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.