Messages in this thread | | | Date | Tue, 10 Jan 2023 08:20:38 +0000 | From | Marc Zyngier <> | Subject | Re: [PATCH v2] arm64: gic: increase the number of IRQ descriptors |
| |
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.
| |