From patchwork Tue Mar 7 14:35:51 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Valentin Schneider X-Patchwork-Id: 1753299 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org; envelope-from=linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=DgpcDl8I; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=OUohGG/J; dkim-atps=neutral Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4PWJhG0Bvhz1yXD for ; Wed, 8 Mar 2023 02:07:10 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=idFLRt4hl+7DxSg8XM5Dc6EaM1hxI6tUcc9bSupimAQ=; b=DgpcDl8IYBV9x4 fzFMxsoEJT1r2khl8XZYYY6d0nNgPdIJBYJy61flr7V7IZbEdkWinksy/7/4F9FX/jMU1Zbkf2AtA 3XFwBVnwdXvpd1qA88gvKIVLfV6ccgCRiQ3a/uaG9zj06ZyEiPbY86ID3IOKag+NpaYmhWvrGRswp 3JQlfZqk6P88cZYMMZgD1KcN3TrYA2SLgHYq6s0S0iyQMVbue23M0bFjkhneuoMPC5TrVYpT0IrvD QtBkLGUVWlOHnlCXGl0NxgsC+upb1SGyLEdbCfzu+OWzKwv86NThvwKE0Ikc/NrCmLvGjpCJAy/WE EAkwxwiv6U7vm+IwHo4A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZYuA-0015Mc-CV; Tue, 07 Mar 2023 15:07:06 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZYQc-000r1p-3w for linux-snps-arc@lists.infradead.org; Tue, 07 Mar 2023 14:36:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678199791; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=yMscSn7/v7gE6eZusBzcl4tSE2iMOh2pPYNqXPmBjFI=; b=OUohGG/J1AReH1N3f63roppCEHTIvJWMC32erNzd6xvJ/34tMeNdMo1wozUgv3cRhRlEZR Yo5Ws6QW0zLD4xrp3xluty7UxMqmZWi0syRUe3r0uJKkAA/zKfgFMNj0cf4fwj5qPb3Nlh gehnaeNN0oniYDkjYPo8bDxdPQ09meU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-635-8Xan7_2yOZyL38nkQLtwpw-1; Tue, 07 Mar 2023 09:36:28 -0500 X-MC-Unique: 8Xan7_2yOZyL38nkQLtwpw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2A55D185A794; Tue, 7 Mar 2023 14:36:26 +0000 (UTC) Received: from vschneid.remote.csb (unknown [10.33.37.13]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3D43B40CF8EE; Tue, 7 Mar 2023 14:36:21 +0000 (UTC) From: Valentin Schneider To: linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, x86@kernel.org Cc: "Paul E. McKenney" , Steven Rostedt , Peter Zijlstra , Thomas Gleixner , Sebastian Andrzej Siewior , Juri Lelli , Daniel Bristot de Oliveira , Marcelo Tosatti , Frederic Weisbecker , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Marc Zyngier , Mark Rutland , Russell King , Nicholas Piggin , Guo Ren , "David S. Miller" Subject: [PATCH v5 0/7] Generic IPI sending tracepoint Date: Tue, 7 Mar 2023 14:35:51 +0000 Message-Id: <20230307143558.294354-1-vschneid@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230307_063634_272947_6DC00EAF X-CRM114-Status: GOOD ( 23.24 ) X-Spam-Score: -0.4 (/) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Background ========== Detecting IPI *reception* is relatively easy, e.g. using trace_irq_handler_{entry,exit} or even just function-trace flush_smp_call_function_queue() for SMP calls. Figuring out their *origin*, is trickier as there is no generic tracepoint tied to e.g. smp_call_function(): Content analysis details: (-0.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [170.10.129.124 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 SPF_NONE SPF: sender does not publish an SPF Record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [170.10.129.124 listed in wl.mailspike.net] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.2 DKIMWL_WL_HIGH DKIMwl.org - High trust sender X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Background ========== Detecting IPI *reception* is relatively easy, e.g. using trace_irq_handler_{entry,exit} or even just function-trace flush_smp_call_function_queue() for SMP calls. Figuring out their *origin*, is trickier as there is no generic tracepoint tied to e.g. smp_call_function(): o AFAIA x86 has no tracepoint tied to sending IPIs, only receiving them (cf. trace_call_function{_single}_entry()). o arm/arm64 do have trace_ipi_raise(), which gives us the target cpus but also a mostly useless string (smp_calls will all be "Function call interrupts"). o Other architectures don't seem to have any IPI-sending related tracepoint. I believe one reason those tracepoints used by arm/arm64 ended up as they were is because these archs used to handle IPIs differently from regular interrupts (the IRQ driver would directly invoke an IPI-handling routine), which meant they never showed up in trace_irq_handler_{entry, exit}. The trace_ipi_{entry,exit} tracepoints gave a way to trace IPI reception but those have become redundant as of: 56afcd3dbd19 ("ARM: Allow IPIs to be handled as normal interrupts") d3afc7f12987 ("arm64: Allow IPIs to be handled as normal interrupts") which gave IPIs a "proper" handler function used through generic_handle_domain_irq(), which makes them show up via trace_irq_handler_{entry, exit}. Changing stuff up ================= Per the above, it would make sense to reshuffle trace_ipi_raise() and move it into generic code. This also came up during Daniel's talk on Osnoise at the CPU isolation MC of LPC 2022 [1]. Now, to be useful, such a tracepoint needs to export: o targeted CPU(s) o calling context The only way to get the calling context with trace_ipi_raise() is to trigger a stack dump, e.g. $(trace-cmd -e ipi* -T echo 42). This is instead introducing a new tracepoint which exports the relevant context (callsite, and requested callback for when the callsite isn't helpful), and is usable by all architectures as it sits in generic code. Another thing worth mentioning is that depending on the callsite, the _RET_IP_ fed to the tracepoint is not always useful - generic_exec_single() doesn't tell you much about the actual callback being sent via IPI, which is why the new tracepoint also has a @callback argument. Patches ======= o Patches 1-5 spread out the tracepoint across relevant sites. Patch 5 ends up sprinkling lots of #include which I'm not the biggest fan of, but is the least horrible solution I've been able to come up with so far. o Patch 7 is trying to be smart about tracing the callback associated with the IPI. This results in having IPI trace events for: o smp_call_function*() o smp_send_reschedule() o irq_work_queue*() o standalone uses of __smp_call_single_queue() This is incomplete, just looking at arm64 there's more IPI types that aren't covered: IPI_CPU_STOP, IPI_CPU_CRASH_STOP, IPI_TIMER, IPI_WAKEUP, but apart from IPI_TIMER (cf. tick_broadcast()), those IPIs are both unfrequent and accompanied with identifiable interference (stopper or cpuhp threads being scheduled). I've added a point in my todolist to handle those in a later series for the sake of completeness, but IMO this is ready to use. Results ======= Using a recent enough libtraceevent (1.7.0 and above): $ trace-cmd record -e 'ipi:*' hackbench $ trace-cmd report hackbench-159 [002] 136.973122: ipi_send_cpumask: cpumask=0 callsite=generic_exec_single+0x33 callback=nohz_csd_func+0x0 hackbench-159 [002] 136.977945: ipi_send_cpumask: cpumask=0 callsite=generic_exec_single+0x33 callback=nohz_csd_func+0x0 hackbench-159 [002] 136.984576: ipi_send_cpumask: cpumask=3 callsite=check_preempt_curr+0x37 callback=0x0 hackbench-159 [002] 136.985996: ipi_send_cpumask: cpumask=0 callsite=generic_exec_single+0x33 callback=nohz_csd_func+0x0 [...] Links ===== [1]: https://youtu.be/5gT57y4OzBM?t=14234 Revisions ========= v4: https://lore.kernel.org/lkml/20230119143619.2733236-1-vschneid@redhat.com/ v3: https://lore.kernel.org/lkml/20221202155817.2102944-1-vschneid@redhat.com/ v2: https://lore.kernel.org/lkml/20221102182949.3119584-1-vschneid@redhat.com/ v1: https://lore.kernel.org/lkml/20221007154145.1877054-1-vschneid@redhat.com/ v5 -> v4 ++++++++ o Rebased against 6.3-rc1 v3 -> v4 ++++++++ o Rebased against 6.2-rc4 Re-ran my coccinelle scripts for the treewide change; only loongarch needed changes o Dropped cpumask trace event field patch (now in 6.2-rc1) o Applied RB and Ack tags Ingo, I wasn't sure if you meant to Ack the whole series or just the patch you replied to, so since I didn't want to unlawfully forge any tag I only added the one. o Did a small pass on comments and changelogs v2 -> v3 ++++++++ o Dropped the generic export of smp_send_reschedule(), turned it into a macro and a bunch of imports o Dropped the send_call_function_single_ipi() macro madness, split it into sched and smp bits using some of Peter's suggestions v1 -> v2 ++++++++ o Ditched single-CPU tracepoint o Changed tracepoint signature to include callback o Changed tracepoint callsite field to void *; the parameter is still UL to save up on casts due to using _RET_IP_. o Fixed linking failures due to not exporting smp_send_reschedule() Valentin Schneider (7): trace: Add trace_ipi_send_cpumask() sched, smp: Trace IPIs sent via send_call_function_single_ipi() smp: Trace IPIs sent via arch_send_call_function_ipi_mask() irq_work: Trace self-IPIs sent via arch_irq_work_raise() treewide: Trace IPIs sent via smp_send_reschedule() smp: reword smp call IPI comment sched, smp: Trace smp callback causing an IPI arch/alpha/kernel/smp.c | 2 +- arch/arc/kernel/smp.c | 2 +- arch/arm/kernel/smp.c | 5 +- arch/arm/mach-actions/platsmp.c | 2 + arch/arm64/kernel/smp.c | 3 +- arch/csky/kernel/smp.c | 2 +- arch/hexagon/kernel/smp.c | 2 +- arch/ia64/kernel/smp.c | 4 +- arch/loongarch/kernel/smp.c | 4 +- arch/mips/include/asm/smp.h | 2 +- arch/mips/kernel/rtlx-cmp.c | 2 + arch/openrisc/kernel/smp.c | 2 +- arch/parisc/kernel/smp.c | 4 +- arch/powerpc/kernel/smp.c | 6 +- arch/powerpc/kvm/book3s_hv.c | 3 + arch/powerpc/platforms/powernv/subcore.c | 2 + arch/riscv/kernel/smp.c | 4 +- arch/s390/kernel/smp.c | 2 +- arch/sh/kernel/smp.c | 2 +- arch/sparc/kernel/smp_32.c | 2 +- arch/sparc/kernel/smp_64.c | 2 +- arch/x86/include/asm/smp.h | 2 +- arch/x86/kvm/svm/svm.c | 4 ++ arch/x86/kvm/x86.c | 2 + arch/xtensa/kernel/smp.c | 2 +- include/linux/smp.h | 11 +++- include/trace/events/ipi.h | 22 +++++++ kernel/irq_work.c | 14 ++++- kernel/sched/core.c | 19 ++++-- kernel/sched/smp.h | 2 +- kernel/smp.c | 78 +++++++++++++++++++----- virt/kvm/kvm_main.c | 2 + 32 files changed, 164 insertions(+), 53 deletions(-) --- 2.31.1