From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> To: Marc Zyngier <maz@kernel.org> Cc: Valentin Schneider <valentin.schneider@arm.com>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Gleixner <tglx@linutronix.de>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Mark Rutland <mark.rutland@arm.com>, sudeep.holla@arm.com Subject: Re: [RFC PATCH v2 00/10] irqchip/irq-gic: Optimize masking by leveraging EOImode=1 Date: Tue, 8 Jun 2021 18:58:47 +0100 [thread overview] Message-ID: <20210608175840.GA15997@lpieralisi> (raw) In-Reply-To: <87a6o0z86t.wl-maz@kernel.org> [+Sudeep] On Tue, Jun 08, 2021 at 04:29:14PM +0100, Marc Zyngier wrote: > [+Mark, since we discussed about this on IRC] > > Hi Valentin, > > On Tue, 01 Jun 2021 11:25:01 +0100, > Valentin Schneider <valentin.schneider@arm.com> wrote: > > > > On 27/05/21 12:17, Marc Zyngier wrote: > > > On Tue, 25 May 2021 18:32:45 +0100, > > > Valentin Schneider <valentin.schneider@arm.com> wrote: > > >> I've tested this on my Ampere eMAG, which uncovered "fun" interactions with > > >> the MSI domains. Did the same trick as the Juno with the pl011. > > >> > > >> pNMIs cause said eMAG to freeze, but that's true even without my patches. I > > >> did try them out under QEMU+KVM and that looked fine, although that means I > > >> only got to test EOImode=0. I'll try to dig into this when I get some more > > >> cycles. > > > > > > That's interesting/worrying. As far as I remember, this machine uses > > > GIC500, which is a well known quantity. If pNMIs are causing issues, > > > that'd probably be a CPU interface problem. Can you elaborate on how > > > you tried to test that part? Just using the below benchmark? > > > > > > > Not even that, it would hang somewhere at boot. Julien suggested offline > > that it might be a problem with the secondaries' PMR initial value, but I > > really never got to do dig into it. > > I just hit a similar problem on an Altra box, which seems to be > related to using PSCI for idle. PSCI has no idea about priority > masking, and enters CPU suspend with interrupt masked at the PMR > level. Good luck waking up from that. Gah. If we can manage to understand which path in psci_cpu_suspend_enter() is causing this problem that'd be great too (it can be both, for different reasons): if (!psci_power_state_loses_context(state)) (1) ret = psci_ops.cpu_suspend(state, 0); else (2) ret = cpu_suspend(state, psci_suspend_finisher); I'd like to understand if the problem is on idle entry or exit (or both depending on the state we are entering). On (1) we would return from the call with the CPU state retained on (2) with CPU context restored (but it rebooted from reset - so the PMR value is gone). I am asking about (2) because I am trying to understand what the power controller does wrt PMR and wake-up IRQs (ie and whether the PMR plays a role in that). Reworded: trying to understand how the PMR behaviour is playing with the power controller wake-up capabilities. Thoughts appreciated. I am sorry that you had to debug this, thank you for that. Lorenzo > I've pushed a test branch at [1]. It'd be really good if you could > have a quick look and let me know if that helps in your case (it > certainly does on the box I have access to). > > Thanks, > > M. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=arm64/nmi-idle > > -- > Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> To: Marc Zyngier <maz@kernel.org> Cc: Valentin Schneider <valentin.schneider@arm.com>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Gleixner <tglx@linutronix.de>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Mark Rutland <mark.rutland@arm.com>, sudeep.holla@arm.com Subject: Re: [RFC PATCH v2 00/10] irqchip/irq-gic: Optimize masking by leveraging EOImode=1 Date: Tue, 8 Jun 2021 18:58:47 +0100 [thread overview] Message-ID: <20210608175840.GA15997@lpieralisi> (raw) In-Reply-To: <87a6o0z86t.wl-maz@kernel.org> [+Sudeep] On Tue, Jun 08, 2021 at 04:29:14PM +0100, Marc Zyngier wrote: > [+Mark, since we discussed about this on IRC] > > Hi Valentin, > > On Tue, 01 Jun 2021 11:25:01 +0100, > Valentin Schneider <valentin.schneider@arm.com> wrote: > > > > On 27/05/21 12:17, Marc Zyngier wrote: > > > On Tue, 25 May 2021 18:32:45 +0100, > > > Valentin Schneider <valentin.schneider@arm.com> wrote: > > >> I've tested this on my Ampere eMAG, which uncovered "fun" interactions with > > >> the MSI domains. Did the same trick as the Juno with the pl011. > > >> > > >> pNMIs cause said eMAG to freeze, but that's true even without my patches. I > > >> did try them out under QEMU+KVM and that looked fine, although that means I > > >> only got to test EOImode=0. I'll try to dig into this when I get some more > > >> cycles. > > > > > > That's interesting/worrying. As far as I remember, this machine uses > > > GIC500, which is a well known quantity. If pNMIs are causing issues, > > > that'd probably be a CPU interface problem. Can you elaborate on how > > > you tried to test that part? Just using the below benchmark? > > > > > > > Not even that, it would hang somewhere at boot. Julien suggested offline > > that it might be a problem with the secondaries' PMR initial value, but I > > really never got to do dig into it. > > I just hit a similar problem on an Altra box, which seems to be > related to using PSCI for idle. PSCI has no idea about priority > masking, and enters CPU suspend with interrupt masked at the PMR > level. Good luck waking up from that. Gah. If we can manage to understand which path in psci_cpu_suspend_enter() is causing this problem that'd be great too (it can be both, for different reasons): if (!psci_power_state_loses_context(state)) (1) ret = psci_ops.cpu_suspend(state, 0); else (2) ret = cpu_suspend(state, psci_suspend_finisher); I'd like to understand if the problem is on idle entry or exit (or both depending on the state we are entering). On (1) we would return from the call with the CPU state retained on (2) with CPU context restored (but it rebooted from reset - so the PMR value is gone). I am asking about (2) because I am trying to understand what the power controller does wrt PMR and wake-up IRQs (ie and whether the PMR plays a role in that). Reworded: trying to understand how the PMR behaviour is playing with the power controller wake-up capabilities. Thoughts appreciated. I am sorry that you had to debug this, thank you for that. Lorenzo > I've pushed a test branch at [1]. It'd be really good if you could > have a quick look and let me know if that helps in your case (it > certainly does on the box I have access to). > > Thanks, > > M. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=arm64/nmi-idle > > -- > Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-06-08 17:59 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-25 17:32 [RFC PATCH v2 00/10] irqchip/irq-gic: Optimize masking by leveraging EOImode=1 Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 01/10] genirq: Add chip flag to denote automatic IRQ (un)masking Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 02/10] genirq: Define irq_ack() and irq_eoi() helpers Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 20:54 ` kernel test robot 2021-05-27 10:55 ` Marc Zyngier 2021-05-27 10:55 ` Marc Zyngier 2021-05-27 10:58 ` Marc Zyngier 2021-05-27 10:58 ` Marc Zyngier 2021-06-01 10:25 ` Valentin Schneider 2021-06-01 10:25 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 03/10] genirq: Employ ack_irq() and eoi_irq() where relevant Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 04/10] genirq: Add handle_strict_flow_irq() flow handler Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 05/10] genirq: Let purely flow-masked ONESHOT irqs through unmask_threaded_irq() Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 06/10] genirq: Don't mask IRQ within flow handler if IRQ is flow-masked Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 07/10] genirq, irq-gic-v3: Make NMI flow handlers use ->irq_ack() if available Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 08/10] irqchip/gic-v3-its: Use irq_chip_ack_parent() Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-27 12:17 ` Marc Zyngier 2021-05-27 12:17 ` Marc Zyngier 2021-06-01 10:25 ` Valentin Schneider 2021-06-01 10:25 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 09/10] irqchip/gic: Convert to handle_strict_flow_irq() Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-27 12:21 ` Marc Zyngier 2021-05-27 12:21 ` Marc Zyngier 2021-06-01 10:25 ` Valentin Schneider 2021-06-01 10:25 ` Valentin Schneider 2021-06-15 15:20 ` Valentin Schneider 2021-06-15 15:20 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 10/10] irqchip/gic-v3: " Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:34 ` [RFC PATCH v2 00/10] irqchip/irq-gic: Optimize masking by leveraging EOImode=1 Valentin Schneider 2021-05-25 17:34 ` Valentin Schneider 2021-05-27 11:17 ` Marc Zyngier 2021-05-27 11:17 ` Marc Zyngier 2021-06-01 10:25 ` Valentin Schneider 2021-06-01 10:25 ` Valentin Schneider 2021-06-03 15:32 ` Valentin Schneider 2021-06-03 15:32 ` Valentin Schneider 2021-06-08 15:29 ` Marc Zyngier 2021-06-08 15:29 ` Marc Zyngier 2021-06-08 17:58 ` Lorenzo Pieralisi [this message] 2021-06-08 17:58 ` Lorenzo Pieralisi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210608175840.GA15997@lpieralisi \ --to=lorenzo.pieralisi@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=sudeep.holla@arm.com \ --cc=tglx@linutronix.de \ --cc=valentin.schneider@arm.com \ --cc=vincenzo.frascino@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.