From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A6C291DEFE8; Thu, 15 Oct 2026 04:47:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792039629; cv=none; b=Ffhnmd+XK98xs9QajJUQm57irCNEKXpqFqlZ8U1J83/nmim9TJqES66SvgMLL9Hh0ZCE+ewu6spmw8g2Hb711Kqa5ikvHrT4gQ0l/2HpXTEKvRTUuk2N5Vvwsk3Na9NZE1ZoTMiusDHEjhLzs6JbKFlae11wLAc26FfBXJkrxWk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792039629; c=relaxed/simple; bh=SOLAHGv8YI5B1XPV2y9FoUywMT1crTijEPj56jqv/Ks=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=auX+DWepg/4Z3B3RQdssuNlTurIuVnjzattKZoB0hCix4SAJ60WLxMPY5pnzxgw18j07ktvDToff/+1Dwqc47jlbKTdcAyRaQn3m2xeaURL6lm2Pdof9Gu01kuYrjLpxgPly2m8OwSWi160mCiVr6aJNlKR+2MhylXOUXAQoEJ0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=W9zOiDWm; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="W9zOiDWm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5487F1F000C4; Thu, 15 Oct 2026 04:47:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792039628; bh=2qUN2dn+UdIt7G2FXNfytZpTzNCQoVGJzHQ0Niz3D8E=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=W9zOiDWmt3r7a1pEH9LVNDElXl1rsDMfFZmoMQ179ppBA6xpFs0FhcfehBnK0vhtW M8XqC38BAcsmq6BHhrusfLWlVDgi4QTb1A+/oA9QkfQu9sjTXZLipaNPnDahkokiK1 9XsZthxRtScJlS/hE1jLbVS/Jd1pS72rx7MNkdanKZpYQvBl4UpyhPYagN4YxnF/iO imyOWQbHg/mqsai1tDMNG5GRG8/B88MMMThA9aB5qhMsJD1f5WsIS2Q5+fW13dpeZL HjLWZs/smlTWXc8XU/0v8b4JvQSz1bNruSOhzCiDsQbAVMDH/dp6+oidCOuyV3bYNd Cy5s3B43OZ93w== Date: Thu, 15 Oct 2026 12:27:05 +0800 From: Jisheng Zhang To: Roman Storozhenko Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH v2] riscv: mm: Trace TLB flush path selection Message-ID: References: <20260830-tlb_tracepoint-v2-1-e3c88c24df5b@gmail.com> Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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.