All of lore.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:20 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 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.