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.
next prev parent 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.