From: Nam Cao <namcao@linutronix.de>
To: Anup Patel <anup@brainfault.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Samuel Holland <samuel.holland@sifive.com>,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
b.spranger@linutronix.de, Christoph Hellwig <hch@lst.de>,
Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [PATCH] irqchip/sifive-plic: Fix plic_set_affinity() only enables 1 cpu
Date: Wed, 3 Jul 2024 14:33:27 +0200 [thread overview]
Message-ID: <20240703123327.CvOiP2Jb@linutronix.de> (raw)
In-Reply-To: <CAAhSdy0ZGD-p0iBVPqHF0RKTwvAAMWwYZ0ufioRrO75JzSh1qQ@mail.gmail.com>
On Wed, Jul 03, 2024 at 05:28:23PM +0530, Anup Patel wrote:
> On Wed, Jul 3, 2024 at 12:57 PM Nam Cao <namcao@linutronix.de> wrote:
> >
> > plic_set_affinity() only enables interrupt for the first possible CPU in
> > the mask. The point is to prevent all CPUs trying to claim an interrupt,
> > but only one CPU succeeds and the other CPUs wasted some clock cycles for
> > nothing.
> >
> > However, there are two problems with that:
> > 1. Users cannot enable interrupt on multiple CPUs (for example, to minimize
> > interrupt latency).
>
> Well, you are assuming that multiple CPUs are always idle or available
> to process interrupts. In other words, if the system is loaded running
> some workload on each CPU then performance on multiple CPUs
> will degrade since multiple CPUs will wastefully try to claim interrupt.
>
> In reality, we can't make such assumptions and it is better to target a
> particular CPU for processing interrupts (just like various other interrupt
> controllers). For balancing interrupt processing load, we have software
> irq balancers running in user-space (or kernel space) which do a
> reasonably fine job of picking appropriate CPU for interrupt processing.
Then we should leave the job of distributing interrupts to those tools,
right? Not all use cases want minimally wasted CPU cycles. For example, if
a particular interrupt does not arrive very often, but when it does, it
needs to be handled fast; in this example, clearly enabling this interrupt
for all CPUs is superior.
But I am sure there are users who don't use something like irqbalance and
just let the system do the default behavior. So I see your point of not
wasting CPU cycles. So, how about we keep this patch, but also add a
"default policy" which evenly distributes the interrupts to individually
CPUs (best effort only). Something like the un-tested patch below?
Best regards,
Nam
diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
index f30bdb94ceeb..953f375835b0 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -312,7 +312,7 @@ static int plic_irqdomain_map(struct irq_domain *d, unsigned int irq,
irq_domain_set_info(d, irq, hwirq, &plic_chip, d->host_data,
handle_fasteoi_irq, NULL, NULL);
irq_set_noprobe(irq);
- irq_set_affinity(irq, &priv->lmask);
+ irq_set_affinity(irq, cpumask_of(cpumask_any_distribute(&priv->lmask)));
return 0;
}
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-07-03 12:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-03 7:26 [PATCH] irqchip/sifive-plic: Fix plic_set_affinity() only enables 1 cpu Nam Cao
2024-07-03 11:58 ` Anup Patel
2024-07-03 12:33 ` Nam Cao [this message]
2024-07-03 15:01 ` Anup Patel
2024-07-07 14:34 ` Nam Cao
2024-07-10 20:19 ` Thomas Gleixner
2024-07-15 19:49 ` Nam Cao
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=20240703123327.CvOiP2Jb@linutronix.de \
--to=namcao@linutronix.de \
--cc=anup@brainfault.org \
--cc=b.spranger@linutronix.de \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=paul.walmsley@sifive.com \
--cc=samuel.holland@sifive.com \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox