From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7AC6DC3064D for ; Fri, 28 Jun 2024 12:41:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xz2Oqsb1aMmhN83CG9iCNooasNZq0FMh9rHMBx7XeeM=; b=rBDVZqrZN3htCgvaHcOnvUG1H0 8GYSI0Mpa1cANIMwN+vuiOa8ebFzDVAeJ5ONw3wFR9Jg3j/lHXzK7nam2PQNKwGkYtqriE+dBybvA m816MTRDlrf4Aq2mff7UBOXY6Y904lKrBar1JM/HPILcswhSadzU7xRFxBl1GgdqTuOLFV5p+qA85 AxOJV7W6STdLVWFJM1yHTeLhUAwU2AqG+kBD00a5rALa2o1A0h5T5GPtWW+ztfMOvDPoD2Bm4O5qa stOtQcQiz5whwBOwZS7zvBXwtp9R73jwvIn1w3ISTlcM2uoYZy7tsoK4bQs2iS6bWFg/J4OgWgADd dmpB4ojA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sNAuO-0000000DiYM-1C4J; Fri, 28 Jun 2024 12:40:56 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sNAuF-0000000DiWB-0BH0 for linux-arm-kernel@lists.infradead.org; Fri, 28 Jun 2024 12:40:48 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C23416206E; Fri, 28 Jun 2024 12:40:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89E85C116B1; Fri, 28 Jun 2024 12:40:44 +0000 (UTC) Date: Fri, 28 Jun 2024 08:41:37 -0400 From: Steven Rostedt To: richard clark Cc: Marc Zyngier , Mark Rutland , will@kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "Russell King (Oracle)" , Linus Torvalds Subject: Re: Will smp_call_function_single(cpu, ...) broadcast IPI to all other cpus? Message-ID: <20240628084137.3338ab75@gandalf.local.home> In-Reply-To: References: <86pls2isal.wl-maz@kernel.org> <20240627101207.0bbbead0@rorschach.local.home> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240628_054047_152465_84651B09 X-CRM114-Status: GOOD ( 16.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 28 Jun 2024 18:21:25 +0800 richard clark wrote: > Hi Steven, >=20 > On Thu, Jun 27, 2024 at 10:12=E2=80=AFPM Steven Rostedt wrote: > > > > On Thu, 27 Jun 2024 11:38:58 +0100 > > Marc Zyngier wrote: > > =20 > > > You may want to enable stack trace recording and find out for yourself > > > where these ipi_raise() calls are coming from. =20 > > > > Try trace-cmd: > > > > # trace-cmd start -e ipi_raise -R 'stacktrace if reason=3D=3D"Functio= n call interrupts"' > > # taskset -c 0 insmod /kmods/ipi_test.ko > > # trace-cmd stop > > # trace-cmd show > > =20 > I found that the 'stacktrace' seems like a stick bit. Run the above > '# trace-cmd start -e ipi_raise -R 'stacktrace if reason=3D=3D"Function > call interrupts"' ... command sequence, then > # trace-cmd start -e ipi -f 'reason=3D=3D"Function call interrupts"' -v -e > ipi_exit; taskset -c 0 insmod /kmods/ipi_lat.ko; trace-cmd stop; > trace-cmd show; trace-cmd clear; > The output is: >=20 > insmod-1746 [000] dn.h1.. 928.400039: ipi_raise: > target_mask=3D00000000,000000ffe (Function call interrupts) > insmod-1746 [000] dn.h2.. 928.400042: > =3D> trace_event_raw_event_ipi_raise > =3D> smp_cross_call > =3D> arch_send_call_function_single_ipi > =3D> send_call_function_single_ipi =20 > ... > Actually, the behavior hoped like this(no stacktrace): >=20 > insmod-1677 [000] ....1.. 473.474846: ipi_raise: > target_mask=3D00000000,00000ffe (Function call interrupts) > -0 [002] d..h1.. 473.474848: ipi_entry: > (Function call interrupts) > -0 [003] d..h1.. 473.474849: ipi_entry: > (Function call interrupts) > ... > insmod-1677 [000] ....1.. 473.474859: ipi_raise: > target_mask=3D00000000,00000ffe (Function call interrupts) > -0 [001] d..h1.. 473.474861: ipi_entry: > (Function call interrupts) magic=3D0x55aa55aa > ... >=20 > I tried to add '# trace-cmd stack --stop/reset' before the above > command, but it did not work. Any help to disable the 'stacktrace' in > this scenario? trace-cmd reset will put everything back. But yeah, I need to fix it so that it's easier to reset triggers. -- Steve