Re: [PATCH v2] arm64: gic: increase the number of IRQ descriptors

From: Shanker Donthineni
Date: Tue Jan 10 2023 - 12:18:48 EST




On 1/10/23 02:20, Marc Zyngier wrote:
External email: Use caution opening links or attachments


On Mon, 09 Jan 2023 17:13:25 +0000,
Shanker Donthineni <sdonthineni@xxxxxxxxxx> 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?


I'll also prototype using XArray data structure instead of IDR based.