Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH v5 1/3] genirq: Use hlist for managing resend handlers | Date | Mon, 29 May 2023 23:51:02 +0200 |
| |
On Mon, May 29 2023 at 15:57, Chang Liao wrote: > 在 2023/5/19 21:49, Shanker Donthineni 写道: >> diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h >> index 844a8e30e6de..d9451d456a73 100644 >> --- a/include/linux/irqdesc.h >> +++ b/include/linux/irqdesc.h >> @@ -102,6 +102,9 @@ struct irq_desc { >> int parent_irq; >> struct module *owner; >> const char *name; >> +#ifdef CONFIG_HARDIRQS_SW_RESEND >> + struct hlist_node resend_node; >> +#endif >> } ____cacheline_internodealigned_in_smp; > > Although there is no documented rule that limits the change of the KABI > struct irq_desc, it is still better to keep the irq_desc definition > stable.
Please read and understand:
Documentation/process/stable-api-nonsense.rst
If you want KABI, then that's _YOUR_ problem, period.
>> -/* Bitmap to handle software resend of interrupts: */ >> -static DECLARE_BITMAP(irqs_resend, IRQ_BITMAP_BITS); >> +/* hlist_head to handle software resend of interrupts: */ >> +static HLIST_HEAD(irq_resend_list); >> +static DEFINE_RAW_SPINLOCK(irq_resend_lock); > > What is the benefit of using hlist here? If you want to enjoy the > low latency of querying elements by key, you must define a hlist table > with a reasonable number of buckets. Otherwise, I don't think the time > complexity of hlist is better than a regular double-linked list, > right?
What's complex about hlist in this case? Please explain.
Thanks,
tglx
| |