From: Pingfan Liu <piliu@redhat.com> To: Mark Rutland <mark.rutland@arm.com> Cc: Pingfan Liu <kernelfans@gmail.com>, linux-arm-kernel@lists.infradead.org, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Sami Tolvanen <samitolvanen@google.com>, Julien Thierry <julien.thierry@arm.com>, Thomas Gleixner <tglx@linutronix.de>, Yuichi Ito <ito-yuichi@fujitsu.com>, linux-kernel@vger.kernel.org Subject: Re: [PATCHv2 4/5] irqchip/GICv3: let gic_handle_irq() utilize irqentry on arm64 Date: Wed, 29 Sep 2021 11:10:11 +0800 [thread overview] Message-ID: <YVPZEwfi8OFkzcd1@piliu.users.ipa.redhat.com> (raw) In-Reply-To: <20210928091053.GD1924@C02TD0UTHF1T.local> On Tue, Sep 28, 2021 at 10:10:53AM +0100, Mark Rutland wrote: > On Fri, Sep 24, 2021 at 09:28:36PM +0800, Pingfan Liu wrote: > > The call to rcu_irq_enter() originated from gic_handle_irq() is > > redundant now, since arm64 has enter_from_kernel_mode() akin to > > irqenter_entry(), which has already called rcu_irq_enter(). > > Here I think you're referring to the call in handle_domain_irq(), but > that isn't clear from the commit message. > Yes, and I will make it clear in V2. > > Based on code analysis, the redundant can raise some mistake, e.g. > > rcu_data->dynticks_nmi_nesting inc 2, which causes > > rcu_is_cpu_rrupt_from_idle() unexpected. > > > > So eliminate the call to irq_enter() in handle_domain_irq(). And > > accordingly supplementing irq_enter_rcu(). > > We support many more irqchips on arm64, and GICv3 can be used on regular > 32-bit arm, so this isn't right. Moving the irq_enter_rcu() call > into the GICv3 driver specifically breaks other drivers on arm64 by > removing the call, and breaks the GICv3 driver on arm by adding a > duplicate call. > Oops. I forgot to protect the code in GICv3 with CONFIG_HAVE_ARCH_IRQENTRY > It looks like this should live in do_interrupt_handler() in > arch/arm64/kernel/entry-common.c, e.g. > > | static void do_interrupt_handler(struct pt_regs *regs, > | void (*handler)(struct pt_regs *)) > | { > | irq_enter_rcu(); > | if (on_thread_stack()) > | call_on_irq_stack(regs, handler); > | else > | handler(regs); > | irq_exit_rcu(); > | } > > ... unless there's some problem with that? > Yeah, do_interrupt_handler() is a more suitable place. But to resolve the performance regression of rescheduling IPI [1], it is badly demanded to distinguish irqnr before calling irq_enter_rcu() (please see 5/5 and [2] for the context). So it is a compromise to host the code in GICv3. Any good idea? [1]: https://lore.kernel.org/linux-arm-kernel/20201101131430.257038-1-maz@kernel.org/ [2]: https://lore.kernel.org/linux-arm-kernel/87lfewnmdz.fsf@nanos.tec.linutronix.de/ Thanks, Pingfan
WARNING: multiple messages have this Message-ID (diff)
From: Pingfan Liu <piliu@redhat.com> To: Mark Rutland <mark.rutland@arm.com> Cc: Pingfan Liu <kernelfans@gmail.com>, linux-arm-kernel@lists.infradead.org, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Sami Tolvanen <samitolvanen@google.com>, Julien Thierry <julien.thierry@arm.com>, Thomas Gleixner <tglx@linutronix.de>, Yuichi Ito <ito-yuichi@fujitsu.com>, linux-kernel@vger.kernel.org Subject: Re: [PATCHv2 4/5] irqchip/GICv3: let gic_handle_irq() utilize irqentry on arm64 Date: Wed, 29 Sep 2021 11:10:11 +0800 [thread overview] Message-ID: <YVPZEwfi8OFkzcd1@piliu.users.ipa.redhat.com> (raw) In-Reply-To: <20210928091053.GD1924@C02TD0UTHF1T.local> On Tue, Sep 28, 2021 at 10:10:53AM +0100, Mark Rutland wrote: > On Fri, Sep 24, 2021 at 09:28:36PM +0800, Pingfan Liu wrote: > > The call to rcu_irq_enter() originated from gic_handle_irq() is > > redundant now, since arm64 has enter_from_kernel_mode() akin to > > irqenter_entry(), which has already called rcu_irq_enter(). > > Here I think you're referring to the call in handle_domain_irq(), but > that isn't clear from the commit message. > Yes, and I will make it clear in V2. > > Based on code analysis, the redundant can raise some mistake, e.g. > > rcu_data->dynticks_nmi_nesting inc 2, which causes > > rcu_is_cpu_rrupt_from_idle() unexpected. > > > > So eliminate the call to irq_enter() in handle_domain_irq(). And > > accordingly supplementing irq_enter_rcu(). > > We support many more irqchips on arm64, and GICv3 can be used on regular > 32-bit arm, so this isn't right. Moving the irq_enter_rcu() call > into the GICv3 driver specifically breaks other drivers on arm64 by > removing the call, and breaks the GICv3 driver on arm by adding a > duplicate call. > Oops. I forgot to protect the code in GICv3 with CONFIG_HAVE_ARCH_IRQENTRY > It looks like this should live in do_interrupt_handler() in > arch/arm64/kernel/entry-common.c, e.g. > > | static void do_interrupt_handler(struct pt_regs *regs, > | void (*handler)(struct pt_regs *)) > | { > | irq_enter_rcu(); > | if (on_thread_stack()) > | call_on_irq_stack(regs, handler); > | else > | handler(regs); > | irq_exit_rcu(); > | } > > ... unless there's some problem with that? > Yeah, do_interrupt_handler() is a more suitable place. But to resolve the performance regression of rescheduling IPI [1], it is badly demanded to distinguish irqnr before calling irq_enter_rcu() (please see 5/5 and [2] for the context). So it is a compromise to host the code in GICv3. Any good idea? [1]: https://lore.kernel.org/linux-arm-kernel/20201101131430.257038-1-maz@kernel.org/ [2]: https://lore.kernel.org/linux-arm-kernel/87lfewnmdz.fsf@nanos.tec.linutronix.de/ Thanks, Pingfan _______________________________________________ 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-09-29 3:11 UTC|newest] Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-24 13:28 [PATCHv2 0/5] arm64/irqentry: remove duplicate housekeeping of Pingfan Liu 2021-09-24 13:28 ` Pingfan Liu 2021-09-24 13:28 ` [PATCHv2 1/5] arm64/entry-common: push the judgement of nmi ahead Pingfan Liu 2021-09-24 13:28 ` Pingfan Liu 2021-09-24 17:53 ` Mark Rutland 2021-09-24 17:53 ` Mark Rutland 2021-09-25 15:39 ` Pingfan Liu 2021-09-25 15:39 ` Pingfan Liu 2021-09-30 13:32 ` Mark Rutland 2021-09-30 13:32 ` Mark Rutland 2021-10-08 4:01 ` Pingfan Liu 2021-10-08 4:01 ` Pingfan Liu 2021-10-08 14:55 ` Pingfan Liu 2021-10-08 14:55 ` Pingfan Liu 2021-10-08 17:25 ` Mark Rutland 2021-10-08 17:25 ` Mark Rutland 2021-10-09 3:49 ` Pingfan Liu 2021-10-09 3:49 ` Pingfan Liu 2021-10-08 15:45 ` Paul E. McKenney 2021-10-08 15:45 ` Paul E. McKenney 2021-10-09 4:14 ` Pingfan Liu 2021-10-09 4:14 ` Pingfan Liu 2021-09-24 13:28 ` [PATCHv2 2/5] irqchip/GICv3: expose handle_nmi() directly Pingfan Liu 2021-09-24 13:28 ` Pingfan Liu 2021-09-24 13:28 ` [PATCHv2 3/5] kernel/irq: make irq_{enter,exit}() in handle_domain_irq() arch optional Pingfan Liu 2021-09-24 13:28 ` [PATCHv2 3/5] kernel/irq: make irq_{enter, exit}() " Pingfan Liu 2021-09-28 8:55 ` [PATCHv2 3/5] kernel/irq: make irq_{enter,exit}() " Mark Rutland 2021-09-28 8:55 ` Mark Rutland 2021-09-29 3:15 ` Pingfan Liu 2021-09-29 3:15 ` Pingfan Liu 2021-09-24 13:28 ` [PATCHv2 4/5] irqchip/GICv3: let gic_handle_irq() utilize irqentry on arm64 Pingfan Liu 2021-09-24 13:28 ` Pingfan Liu 2021-09-28 9:10 ` Mark Rutland 2021-09-28 9:10 ` Mark Rutland 2021-09-29 3:10 ` Pingfan Liu [this message] 2021-09-29 3:10 ` Pingfan Liu 2021-09-29 7:20 ` Marc Zyngier 2021-09-29 7:20 ` Marc Zyngier 2021-09-29 8:27 ` Pingfan Liu 2021-09-29 8:27 ` Pingfan Liu 2021-09-29 9:23 ` Mark Rutland 2021-09-29 9:23 ` Mark Rutland 2021-09-29 11:40 ` Pingfan Liu 2021-09-29 11:40 ` Pingfan Liu 2021-09-29 14:29 ` Pingfan Liu 2021-09-29 14:29 ` Pingfan Liu 2021-09-29 17:41 ` Mark Rutland 2021-09-29 17:41 ` Mark Rutland 2021-09-24 13:28 ` [PATCHv2 5/5] irqchip/GICv3: make reschedule-ipi light weight Pingfan Liu 2021-09-24 13:28 ` Pingfan Liu 2021-09-29 7:24 ` Marc Zyngier 2021-09-29 7:24 ` Marc Zyngier 2021-09-29 8:32 ` Pingfan Liu 2021-09-29 8:32 ` Pingfan Liu 2021-09-24 17:36 ` [PATCHv2 0/5] arm64/irqentry: remove duplicate housekeeping of Mark Rutland 2021-09-24 17:36 ` Mark Rutland 2021-09-24 22:59 ` Paul E. McKenney 2021-09-24 22:59 ` Paul E. McKenney 2021-09-27 9:23 ` Mark Rutland 2021-09-27 9:23 ` Mark Rutland 2021-09-28 0:09 ` Paul E. McKenney 2021-09-28 0:09 ` Paul E. McKenney 2021-09-28 8:32 ` Mark Rutland 2021-09-28 8:32 ` Mark Rutland 2021-09-28 8:35 ` Mark Rutland 2021-09-28 8:35 ` Mark Rutland 2021-09-28 9:52 ` Sven Schnelle 2021-09-28 9:52 ` Sven Schnelle 2021-09-28 10:26 ` Mark Rutland 2021-09-28 10:26 ` Mark Rutland 2021-09-28 13:55 ` Paul E. McKenney 2021-09-28 13:55 ` Paul E. McKenney 2021-09-25 15:12 ` Pingfan Liu 2021-09-25 15:12 ` Pingfan Liu
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=YVPZEwfi8OFkzcd1@piliu.users.ipa.redhat.com \ --to=piliu@redhat.com \ --cc=catalin.marinas@arm.com \ --cc=ito-yuichi@fujitsu.com \ --cc=joey.gouly@arm.com \ --cc=julien.thierry@arm.com \ --cc=kernelfans@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=samitolvanen@google.com \ --cc=tglx@linutronix.de \ --cc=will@kernel.org \ /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.