On Thu, Oct 15, 2026 at 7:08 PM Roman Storozhenko <[email protected]> wrote: > > 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.
And quick v4, where I removed unnecessary cleaning for checkpatch: https://lore.kernel.org/all/[email protected]/ > > -- > Kind regards, > Roman 'Hedin' Storozhenko -- Kind regards, Roman 'Hedin' Storozhenko
