All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Shanker Donthineni <sdonthineni@nvidia.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] arm64: gic: increase the number of IRQ descriptors
Date: Tue, 10 Jan 2023 08:20:38 +0000	[thread overview]
Message-ID: <87pmbmer6x.wl-maz@kernel.org> (raw)
In-Reply-To: <ed471259-5d32-e93b-20d6-42a32b8b3d89@nvidia.com>

On Mon, 09 Jan 2023 17:13:25 +0000,
Shanker Donthineni <sdonthineni@nvidia.com> wrote:
> 
> >>> I'm happy to help with it, but I'm certainly not willing to accept any
> >>> sort of new compile-time limit.
> >> 
> >> Thanks for helping with a scalable solution instead of static
> >> allocation.  Please include me whenever patches posted to LKML. I'm
> >> happy to verify on NVIDIA server platforms and provide test
> >> feedback.
> >> 
> > 
> > I offered to help you. I didn't offer to do the work for you! ;-)
> > 
> 
> I've looked at the IDR/IDA API. There is no suitable function for
> allocating contiguous IDs to replace bitmap API.
> 
> __irq_alloc_descs():
> 
> 	mutex_lock(&sparse_irq_lock);
> 
> 	start = bitmap_find_next_zero_area(allocated_irqs, IRQ_BITMAP_BITS,
> 					   from, cnt, 0);
> 	ret = -EEXIST;
> 
> Is there any existing API that I can use for allocating contiguous IDs?

I think you should address the problem the other way around, as there
are lower hanging fruits:

- turn the irq_desc_tree radix tree into a XArray

- use the XArray mark feature to reimplement the irqs_resend bitmap

Once you have done that, you have already halved the memory usage.
To implement the allocated_irqs bitmap functionality, you have a
bunch of options:

- make the XArray an allocating XArray, and iterate over XA_FREE_MARK
  to find the free range (see how the infiniband subsystem is doing
  exactly that)

- use another Xarray mark to annotate the allocated IRQs, find the
  distance between two allocations, and use this range if the request
  fits (a poor man's variation of the above)

- use a sideband data structure such as the GICv3 LPI allocator, which
  is already dealing with range allocation (I'd rather avoid that)

- something else?

It should be fairly straightforward to perform the conversion in
place.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Shanker Donthineni <sdonthineni@nvidia.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] arm64: gic: increase the number of IRQ descriptors
Date: Tue, 10 Jan 2023 08:20:38 +0000	[thread overview]
Message-ID: <87pmbmer6x.wl-maz@kernel.org> (raw)
In-Reply-To: <ed471259-5d32-e93b-20d6-42a32b8b3d89@nvidia.com>

On Mon, 09 Jan 2023 17:13:25 +0000,
Shanker Donthineni <sdonthineni@nvidia.com> wrote:
> 
> >>> I'm happy to help with it, but I'm certainly not willing to accept any
> >>> sort of new compile-time limit.
> >> 
> >> Thanks for helping with a scalable solution instead of static
> >> allocation.  Please include me whenever patches posted to LKML. I'm
> >> happy to verify on NVIDIA server platforms and provide test
> >> feedback.
> >> 
> > 
> > I offered to help you. I didn't offer to do the work for you! ;-)
> > 
> 
> I've looked at the IDR/IDA API. There is no suitable function for
> allocating contiguous IDs to replace bitmap API.
> 
> __irq_alloc_descs():
> 
> 	mutex_lock(&sparse_irq_lock);
> 
> 	start = bitmap_find_next_zero_area(allocated_irqs, IRQ_BITMAP_BITS,
> 					   from, cnt, 0);
> 	ret = -EEXIST;
> 
> Is there any existing API that I can use for allocating contiguous IDs?

I think you should address the problem the other way around, as there
are lower hanging fruits:

- turn the irq_desc_tree radix tree into a XArray

- use the XArray mark feature to reimplement the irqs_resend bitmap

Once you have done that, you have already halved the memory usage.
To implement the allocated_irqs bitmap functionality, you have a
bunch of options:

- make the XArray an allocating XArray, and iterate over XA_FREE_MARK
  to find the free range (see how the infiniband subsystem is doing
  exactly that)

- use another Xarray mark to annotate the allocated IRQs, find the
  distance between two allocations, and use this range if the request
  fits (a poor man's variation of the above)

- use a sideband data structure such as the GICv3 LPI allocator, which
  is already dealing with range allocation (I'd rather avoid that)

- something else?

It should be fairly straightforward to perform the conversion in
place.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2023-01-10  8:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-04  2:37 [PATCH v2] arm64: gic: increase the number of IRQ descriptors Shanker Donthineni
2023-01-04  2:37 ` Shanker Donthineni
2023-01-04  9:14 ` Marc Zyngier
2023-01-04  9:14   ` Marc Zyngier
2023-01-04 13:47   ` Shanker Donthineni
2023-01-04 13:47     ` Shanker Donthineni
2023-01-05 10:59     ` Marc Zyngier
2023-01-05 10:59       ` Marc Zyngier
2023-01-05 14:47       ` Shanker Donthineni
2023-01-05 14:47         ` Shanker Donthineni
2023-01-09 16:41         ` Marc Zyngier
2023-01-09 16:41           ` Marc Zyngier
2023-01-09 16:57           ` Shanker Donthineni
2023-01-09 16:57             ` Shanker Donthineni
2023-01-09 17:13           ` Shanker Donthineni
2023-01-09 17:13             ` Shanker Donthineni
2023-01-10  8:20             ` Marc Zyngier [this message]
2023-01-10  8:20               ` Marc Zyngier
2023-01-10 14:22               ` Shanker Donthineni
2023-01-10 14:22                 ` Shanker Donthineni
2023-01-10 22:36                 ` Thomas Gleixner
2023-01-10 22:36                   ` Thomas Gleixner
2023-01-30  1:32                   ` Shanker Donthineni
2023-01-30  1:32                     ` Shanker Donthineni
2023-01-10 17:17               ` Shanker Donthineni
2023-01-10 17:17                 ` Shanker Donthineni

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=87pmbmer6x.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sdonthineni@nvidia.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.