[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <875xewu8k8.wl-maz@kernel.org>
Date: Sat, 09 Aug 2025 10:51:35 +0100
From: Marc Zyngier <maz@...nel.org>
To: Jinjie Ruan <ruanjinjie@...wei.com>
Cc: <lpieralisi@...nel.org>,
<tglx@...utronix.de>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH -next] irqchip/gic-v5: Improve the SPI alloc efficiency
On Sat, 09 Aug 2025 10:29:20 +0100,
Jinjie Ruan <ruanjinjie@...wei.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.
Powered by blists - more mailing lists