From: John Garry <john.garry@huawei.com>
To: Marc Zyngier <maz@kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Cc: chenxiang <chenxiang66@hisilicon.com>,
Zhou Wang <wangzhou1@hisilicon.com>,
Ming Lei <ming.lei@redhat.com>,
Jason Cooper <jason@lakedaemon.net>,
Thomas Gleixner <tglx@linutronix.de>, <kernel-team@android.com>
Subject: Re: [PATCH v4 0/2] irqchip/gic-v3-its: Balance LPI affinity across CPUs
Date: Fri, 15 May 2020 19:09:16 +0100 [thread overview]
Message-ID: <f87f34fa-a512-7f73-2f53-85333257dd8e@huawei.com> (raw)
In-Reply-To: <20200515165752.121296-1-maz@kernel.org>
On 15/05/2020 17:57, Marc Zyngier wrote:
> When mapping a LPI, the ITS driver picks the first possible
> affinity, which is in most cases CPU0, assuming that if
> that's not suitable, someone will come and set the affinity
> to something more interesting.
>
> It apparently isn't the case, and people complain of poor
> performance when many interrupts are glued to the same CPU.
> So let's place the interrupts by finding the "least loaded"
> CPU (that is, the one that has the fewer LPIs mapped to it).
> So called 'managed' interrupts are an interesting case where
> the affinity is actually dictated by the kernel itself, and
> we should honor this.
>
Cheers Marc, I ran these again and the figures look good:
NVMe with nvme.use_threaded_interrupts=1/0
Before: 1000K/1100K IOPS
After: 1100K/1400K IOPS
For some reason v5.7-rc5 looks more stable than rc4 (which I tested
previously).
Tested-by: John Garry <john.garry@huawei.com>
> * From v3:
> - Always pre-decrement/post-increment affinity to avoid useless
> changes of affinity (John)
> - Don't use the node mask as a superset of the proposed affinity
> as the ACPI tables can't really describe this (John)
> - Rebased on v5.7-rc5
>
> * From v2:
> - Split accounting from CPU selection
> - Track managed and unmanaged interrupts separately
>
> Marc Zyngier (2):
> irqchip/gic-v3-its: Track LPI distribution on a per CPU basis
> irqchip/gic-v3-its: Balance initial LPI affinity across CPUs
>
> drivers/irqchip/irq-gic-v3-its.c | 170 ++++++++++++++++++++++++++-----
> 1 file changed, 143 insertions(+), 27 deletions(-)
>
prev parent reply other threads:[~2020-05-15 18:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 16:57 [PATCH v4 0/2] irqchip/gic-v3-its: Balance LPI affinity across CPUs Marc Zyngier
2020-05-15 16:57 ` [PATCH v4 1/2] irqchip/gic-v3-its: Track LPI distribution on a per CPU basis Marc Zyngier
2020-05-30 7:46 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-05-15 16:57 ` [PATCH v4 2/2] irqchip/gic-v3-its: Balance initial LPI affinity across CPUs Marc Zyngier
2020-05-15 18:09 ` John Garry [this message]
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=f87f34fa-a512-7f73-2f53-85333257dd8e@huawei.com \
--to=john.garry@huawei.com \
--cc=chenxiang66@hisilicon.com \
--cc=jason@lakedaemon.net \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=ming.lei@redhat.com \
--cc=tglx@linutronix.de \
--cc=wangzhou1@hisilicon.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: 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;
as well as URLs for NNTP newsgroup(s).