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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C46C2C41513 for ; Mon, 7 Aug 2023 16:04:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230076AbjHGQEY (ORCPT ); Mon, 7 Aug 2023 12:04:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46452 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229645AbjHGQEW (ORCPT ); Mon, 7 Aug 2023 12:04:22 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EFCAA10C4; Mon, 7 Aug 2023 09:04:20 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5E2191FB; Mon, 7 Aug 2023 09:05:03 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.32.139]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A1FF83F59C; Mon, 7 Aug 2023 09:04:17 -0700 (PDT) Date: Mon, 7 Aug 2023 17:04:14 +0100 From: Mark Rutland To: Daniel Thompson Cc: Douglas Anderson , Catalin Marinas , Will Deacon , Sumit Garg , Marc Zyngier , linux-perf-users@vger.kernel.org, ito-yuichi@fujitsu.com, Chen-Yu Tsai , Ard Biesheuvel , Stephen Boyd , Peter Zijlstra , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, kgdb-bugreport@lists.sourceforge.net, Masayoshi Mizuma , "Rafael J . Wysocki" , Lecopzer Chen , Wei Li , linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 7/7] arm64: kgdb: Roundup cpus using the debug IPI Message-ID: References: <20230601213440.2488667-1-dianders@chromium.org> <20230601143109.v9.7.I2ef26d1b3bfbed2d10a281942b0da7d9854de05e@changeid> <20230807152444.GA375529@aspen.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230807152444.GA375529@aspen.lan> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 07, 2023 at 04:24:44PM +0100, Daniel Thompson wrote: > On Mon, Aug 07, 2023 at 11:28:52AM +0100, Mark Rutland wrote: > > On Thu, Jun 01, 2023 at 02:31:51PM -0700, Douglas Anderson wrote: > > > From: Sumit Garg > > > > > > Let's use the debug IPI for rounding up CPUs in kgdb. When the debug > > > IPI is backed by an NMI (or pseudo NMI) then this will let us debug > > > even hard locked CPUs. When the debug IPI isn't backed by an NMI then > > > this won't really have any huge benefit but it will still work. > > > > > > Signed-off-by: Sumit Garg > > > Signed-off-by: Douglas Anderson > > > --- > > > > > > Changes in v9: > > > - Remove fallback for when debug IPI isn't available. > > > - Renamed "NMI IPI" to "debug IPI" since it might not be backed by NMI. > > > > > > arch/arm64/kernel/ipi_debug.c | 5 +++++ > > > arch/arm64/kernel/kgdb.c | 14 ++++++++++++++ > > > 2 files changed, 19 insertions(+) > > > > This looks fine to me, but I'd feel a bit happier if we had separate SGIs for > > the backtrace and the KGDB callback as they're logically unrelated. > > I've no objections to seperate SGIs (if one can be found) but I'm curious > what benefit emerges from giving them seperate IPIs. Mostly an "I'd feel happier"; they're logically unrelated and having them separate avoids the risk of them unintentionally getting in the way of the other. > Both interfaces are already designed to share and NMI-like IPI nicely > (and IIUC they must share one on x86), neither is performance > critical[1] and the content of /proc/interrupts for the IPI is seldom > going to be of much interest. Sure; I understand that. The flip side of "neither is performance critical" is that they're seldom tested in terms of interaction with one another, and hence for robustness I'd prefer they're separate. I agree it's not strictly necessary, but given we can easily free up an SGI slot, I think it'd be worthwhile. We can always decide to fold them together in future if we have to. I realise a similar argument could be applied to IPI_WAKEUP and IPI_RESCHEDULE, but given that IPI_RESCHEDULE happens *all the time* and the wakeup handler does literally nothing, I think the risk there is substantially lower. Thanks, Mark. > As mentioned it is perfectly OK to separate them if there is space in > the SGI allocations. However if any two functions are good candidates to > share a scarce resource such as an SGI then it is these! > > > Daniel. > > > [1] In both cases their results are only required at human-scale > and the work of the both handlers is hugely more expensive than > either up front quick-check.