Messages in this thread | | | Date | Mon, 7 Aug 2023 17:04:14 +0100 | From | Mark Rutland <> | Subject | Re: [PATCH v9 7/7] arm64: kgdb: Roundup cpus using the debug IPI |
| |
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 <sumit.garg@linaro.org> > > > > > > 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 <sumit.garg@linaro.org> > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > > --- > > > > > > 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.
| |