From: Marc Zyngier <maz@kernel.org>
To: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: <lpieralisi@kernel.org>, <tglx@linutronix.de>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH -next] irqchip/gic-v5: Improve the SPI alloc efficiency
Date: Sat, 09 Aug 2025 10:51:35 +0100 [thread overview]
Message-ID: <875xewu8k8.wl-maz@kernel.org> (raw)
In-Reply-To: <20250809092920.3765609-1-ruanjinjie@huawei.com>
On Sat, 09 Aug 2025 10:29:20 +0100,
Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
> If the GICv5 system has a large number of PEs and IRS components,
> traversing the linked list to find the irs_data corresponding
> to a specific SPI interrupt will be very slow.
Define "very slow".
>
> Since the maximum number of IRS nodes, the minimum and maximum SPI
> interrupt numbers for each IRS is known during the initialization
> of the IRS nodes, sort the IRS nodes by interrupt number at
> the initial stage. This way, when allocating SPI interrupts, we can
> directly perform a binary search on the irs_data
> using the SPI interrupt number with O(log N) complexity.
Here we go again... Frankly, before we start optimising the crap out
of this, I really want numbers:
- How many IRSs to you imagine having? 2? 64? 4096?
- How often do we walk that list?
I can't answer the first question, but I can definitely answer the
second one: we do it exactly *ONCE* per SPI, at the point of
allocation. And once it is allocated, we don't do it again.
Unless you demonstrate, with actual figures taken from actual
hardware, that what we have is not good enough, that we need some
binary search to walk the thousands of IRSs that you have in your
system and that it actually affects performance, I don't buy it at
all.
Premature optimisation, evil, and all that jazz...
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
prev parent reply other threads:[~2025-08-09 9:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-09 9:29 [RFC PATCH -next] irqchip/gic-v5: Improve the SPI alloc efficiency Jinjie Ruan
2025-08-09 9:51 ` Marc Zyngier [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=875xewu8k8.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=ruanjinjie@huawei.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 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.