public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Marc Zyngier <maz@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	Timothy Hayes <timothy.hayes@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	ast@kernel.org
Subject: Re: [PATCH 20/24] irqchip/gic-v5: Add GICv5 LPI/IPI support
Date: Tue, 15 Apr 2025 10:08:14 +0200	[thread overview]
Message-ID: <Z/4T7lpXSFgomIai@lpieralisi> (raw)
In-Reply-To: <4vtbkgtp5c7vdfdzof46l3fjwwsd66j3tynxub4png57zcau7h@k2treu5vgn42>

On Mon, Apr 14, 2025 at 10:37:57AM -0400, Liam R. Howlett wrote:

[...]

> > I can go for an IDA unless someone see a point in pursuing the current
> > approach - that I would update according to feedback, at least with
> > this thread you get the full picture.
> 
> Eventually, we plan to swap out the backing of the IDA to use the maple
> tree.  I think we could add range support as part of this change.
> 
> If you were to add an interface to contiguous allocate a number of IDAs
> by putting your loop in the IDA interface, we'd be able to switch that
> to a range store during the conversion and keep the use case visible
> during the planning stages.
> 
> Having that interface would make it obvious the change is necessary and
> wouldn't be missed.

Yep understood but on the other hand it would force me to allocate a set
of contiguous IDs, which is a bit cumbersome with the current IDA
(alloc them one by one - if any fails to be contiguous restart, rince,
repeat - it is a double whammy).

I allocate a range because I know the maple tree handle them efficiently
and to be honest, a range allocator is all I need, there isn't any in
the core kernel (there are plenty - on purpose - range allocators, BPF
range tree and GICv3 ITS LPIs allocator are good examples, I could reuse
them instead of reinventing the wheel).

FWIW, when Alexei implemented the BPF arena he vetted other examples.

https://lore.kernel.org/bpf/20241105212001.38980-1-alexei.starovoitov@gmail.com/

I don't think the code I wrote is that complex either and it minimizes
entry storage waste - probably you don't want to see it in the kernel
because it is not a MT usage you'd expect - storage wise, I need to
measure it but I think it definitely requires fewer bytes than a
preallocated bitmap - when the IDA range API is in I would be glad
to swap to it.

> Unfortunately, I don't really have a timeline on changing the IDA to the
> maple tree.

I understand, it is a chicken and egg situation, see above.

> Please keep me Cc'ed on whatever you decide.

I'd need something promptly, so I will go for a simple solution (bitmap
or IDA 1-by-1) if the current MT one has to be scrapped.

Thank you,
Lorenzo

  reply	other threads:[~2025-04-15  8:08 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 10:49 [PATCH 00/24] Arm GICv5: Host driver implementation Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 01/24] Documentation: devicetree: bindings: Add GICv5 DT bindings Lorenzo Pieralisi
2025-04-08 12:26   ` Rob Herring (Arm)
2025-04-08 14:58     ` Lorenzo Pieralisi
2025-04-08 15:07   ` Rob Herring
2025-04-09  8:20     ` Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 02/24] arm64/sysreg: Add GCIE field to ID_AA64PFR2_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 03/24] arm64/sysreg: Add ICC_PPI_PRIORITY<n>_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 04/24] arm64/sysreg: Add ICC_ICSR_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 05/24] arm64/sysreg: Add ICC_PPI_HMR<n>_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 06/24] arm64/sysreg: Add ICC_PPI_ENABLER<n>_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 07/24] arm64/sysreg: Add ICC_PPI_{C/S}ACTIVER<n>_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 08/24] arm64/sysreg: Add ICC_PPI_{C/S}PENDR<n>_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 09/24] arm64/sysreg: Add ICC_CR0_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 10/24] arm64/sysreg: Add ICC_PCR_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 11/24] arm64/sysreg: Add ICC_IDR0_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 12/24] arm64/sysreg: Add ICH_HFGRTR_EL2 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 13/24] arm64/sysreg: Add ICH_HFGWTR_EL2 Lorenzo Pieralisi
2025-04-09  7:48   ` Arnd Bergmann
2025-04-09  8:51     ` Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 14/24] arm64/sysreg: Add ICH_HFGITR_EL2 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 15/24] arm64: Disable GICv5 read/write/instruction traps Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 16/24] arm64: cpucaps: Add GCIE capability Lorenzo Pieralisi
2025-04-08 11:26   ` Mark Rutland
2025-04-08 15:02     ` Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 17/24] arm64: smp: Support non-SGIs for IPIs Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 18/24] irqchip/gic-v5: Add GICv5 PPI support Lorenzo Pieralisi
2025-04-08 21:42   ` Thomas Gleixner
2025-04-09  7:30     ` Lorenzo Pieralisi
2025-04-17 14:49       ` Lorenzo Pieralisi
2025-04-11 17:06     ` Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 19/24] irqchip/gic-v5: Add GICv5 IRS/SPI support Lorenzo Pieralisi
2025-04-09  7:02   ` Thomas Gleixner
2025-04-09  7:40     ` Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 20/24] irqchip/gic-v5: Add GICv5 LPI/IPI support Lorenzo Pieralisi
2025-04-09  8:23   ` Arnd Bergmann
2025-04-09 10:11     ` Lorenzo Pieralisi
2025-04-09 10:56       ` Arnd Bergmann
2025-04-09 13:15         ` Lorenzo Pieralisi
2025-04-09 14:25           ` Arnd Bergmann
2025-04-18  9:21         ` Lorenzo Pieralisi
2025-04-09  8:27   ` Thomas Gleixner
2025-04-09 10:30     ` Lorenzo Pieralisi
2025-04-11  9:26   ` Lorenzo Pieralisi
2025-04-11  9:55     ` Thomas Gleixner
2025-04-11 12:37       ` Lorenzo Pieralisi
2025-04-12 13:01         ` Liam R. Howlett
2025-04-14  8:26           ` Lorenzo Pieralisi
2025-04-14 14:37             ` Liam R. Howlett
2025-04-15  8:08               ` Lorenzo Pieralisi [this message]
2025-04-08 10:50 ` [PATCH 21/24] irqchip/gic-v5: Enable GICv5 SMP booting Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 22/24] irqchip/gic-v5: Add GICv5 ITS support Lorenzo Pieralisi
2025-04-09 11:13   ` Thomas Gleixner
2025-04-09 13:37     ` Lorenzo Pieralisi
2025-04-09 18:57   ` Thomas Gleixner
2025-04-10  8:08     ` Lorenzo Pieralisi
2025-04-10  9:20       ` Thomas Gleixner
2025-04-08 10:50 ` [PATCH 23/24] irqchip/gic-v5: Add GICv5 IWB support Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 24/24] arm64: Kconfig: Enable GICv5 Lorenzo Pieralisi
2025-04-09 13:44   ` kernel test robot
2025-04-09 14:04     ` Lorenzo Pieralisi
2025-04-09 14:07       ` Krzysztof Kozlowski

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=Z/4T7lpXSFgomIai@lpieralisi \
    --to=lpieralisi@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=ast@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=robh@kernel.org \
    --cc=sascha.bischoff@arm.com \
    --cc=tglx@linutronix.de \
    --cc=timothy.hayes@arm.com \
    --cc=will@kernel.org \
    /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