lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ