On Thu, Oct 15, 2026 at 6:47 AM Jisheng Zhang <[email protected]> wrote: > > 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: > > 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.
Thanks, I see your point now. I was treating SBI RFENCE vs the Linux cross-CPU path as part of the per-request selection, but with the current implementation riscv_sbi_for_rfence is effectively a system-wide choice established during initialization. I reworked the patch in v3 based on your feedback. The tracepoint no longer reports the local/SBI RFENCE/cross-CPU implementation path. Instead, it describes the semantic TLB invalidation request itself, including the range, stride, ASID, target CPU mask and request scope. I still think there is value in exposing this information as one semantic event. The individual pieces can be reconstructed with dynamic tracing, but having them together makes it straightforward to analyze the distribution and characteristics of TLB invalidations across a workload without depending on the current implementation details. The v3 patch is here: https://lore.kernel.org/all/[email protected]/ Thanks for pointing out the distinction. It helped simplify the event and make its abstraction clearer. -- Kind regards, Roman 'Hedin' Storozhenko
