From: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
Hanks Chen <hanks.chen@mediatek.com>,
Cheng-Yuh.Wu@mediatek.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] irqchip/gic-v3: Workaround for GIC-700 erratum 2941627
Date: Tue, 4 Jul 2023 17:27:45 +0200 [thread overview]
Message-ID: <ZKQ6ce1pbYHGVIsA@lpieralisi> (raw)
In-Reply-To: <86ttujwxb1.wl-maz@kernel.org>
On Tue, Jul 04, 2023 at 03:44:50PM +0100, Marc Zyngier wrote:
[...]
> > + return !((gic_irq_in_rdist(d)) || gic_irq(d) >= 8192 ||
> > + cpumask_equal(irq_data_get_effective_affinity_mask(d),
> > + cpumask_of(smp_processor_id())));
>
> I dislike this statement for multiple reasons:
>
> - it is written as a negation, making it harder than strictly
> necessary to parse as it is the opposite of the comment above
>
> - gic_irq_in_rdist() and gic_irq(d) >= 8192 are two ways of checking
> the interrupt range -- maybe we should just do that
>
> - cpumask_equal() is *slow* if you have more that 64 CPUs, something
> that is increasingly common -- a better option would be to check
> whether the current CPU is in the mask or not, which would be enough
> as we only have a single affinity bit set
>
> - smp_processor_id() can check for preemption, which is pointless
> here, as we're doing things under the irq_desc raw spinlock.
>
> I would expect something like:
>
> enum gic_intid_range range = get_intid_range(d);
>
> return (range == SGI_RANGE || range == ESPI_RANGE) &&
> !cpumask_test_cpu(raw_smp_processor_id(),
> irq_data_get_effective_affinity_mask(d));
>
s/SGI/SPI - just noticed, for the records.
Thanks,
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
Hanks Chen <hanks.chen@mediatek.com>,
Cheng-Yuh.Wu@mediatek.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] irqchip/gic-v3: Workaround for GIC-700 erratum 2941627
Date: Tue, 4 Jul 2023 17:27:45 +0200 [thread overview]
Message-ID: <ZKQ6ce1pbYHGVIsA@lpieralisi> (raw)
In-Reply-To: <86ttujwxb1.wl-maz@kernel.org>
On Tue, Jul 04, 2023 at 03:44:50PM +0100, Marc Zyngier wrote:
[...]
> > + return !((gic_irq_in_rdist(d)) || gic_irq(d) >= 8192 ||
> > + cpumask_equal(irq_data_get_effective_affinity_mask(d),
> > + cpumask_of(smp_processor_id())));
>
> I dislike this statement for multiple reasons:
>
> - it is written as a negation, making it harder than strictly
> necessary to parse as it is the opposite of the comment above
>
> - gic_irq_in_rdist() and gic_irq(d) >= 8192 are two ways of checking
> the interrupt range -- maybe we should just do that
>
> - cpumask_equal() is *slow* if you have more that 64 CPUs, something
> that is increasingly common -- a better option would be to check
> whether the current CPU is in the mask or not, which would be enough
> as we only have a single affinity bit set
>
> - smp_processor_id() can check for preemption, which is pointless
> here, as we're doing things under the irq_desc raw spinlock.
>
> I would expect something like:
>
> enum gic_intid_range range = get_intid_range(d);
>
> return (range == SGI_RANGE || range == ESPI_RANGE) &&
> !cpumask_test_cpu(raw_smp_processor_id(),
> irq_data_get_effective_affinity_mask(d));
>
s/SGI/SPI - just noticed, for the records.
Thanks,
Lorenzo
next prev parent reply other threads:[~2023-07-04 15:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-04 12:34 [PATCH] irqchip/gic-v3: Workaround for GIC-700 erratum 2941627 Lorenzo Pieralisi
2023-07-04 12:34 ` Lorenzo Pieralisi
2023-07-04 14:44 ` Marc Zyngier
2023-07-04 14:44 ` Marc Zyngier
2023-07-04 15:14 ` Lorenzo Pieralisi
2023-07-04 15:14 ` Lorenzo Pieralisi
2023-07-04 15:23 ` Marc Zyngier
2023-07-04 15:23 ` Marc Zyngier
2023-07-04 15:27 ` Lorenzo Pieralisi [this message]
2023-07-04 15:27 ` Lorenzo Pieralisi
2023-07-04 15:31 ` Marc Zyngier
2023-07-04 15:31 ` Marc Zyngier
2023-07-04 15:50 ` [PATCH v2] " Lorenzo Pieralisi
2023-07-04 15:50 ` Lorenzo Pieralisi
2023-07-17 12:57 ` [irqchip: irq/irqchip-fixes] " irqchip-bot for Lorenzo Pieralisi
-- strict thread matches above, loose matches on Subject: below --
2023-07-07 11:45 [PATCH] " Chunhui Li (李春辉)
2023-07-07 12:14 Chunhui Li (李春辉)
2023-07-09 8:20 ` Marc Zyngier
2023-07-09 8:20 ` Marc Zyngier
2023-07-10 6:00 ` Chunhui Li (李春辉)
2023-07-10 6:00 ` Chunhui Li (李春辉)
2023-07-11 2:03 ` Chunhui Li (李春辉)
2023-07-11 2:03 ` Chunhui Li (李春辉)
2023-07-12 1:40 Chunhui Li (李春辉)
2023-07-12 7:21 ` Marc Zyngier
2023-07-12 7:21 ` Marc Zyngier
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=ZKQ6ce1pbYHGVIsA@lpieralisi \
--to=lpieralisi@kernel.org \
--cc=Cheng-Yuh.Wu@mediatek.com \
--cc=hanks.chen@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@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: link
Be 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.