[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871qiylsc9.ffs@tglx>
Date: Mon, 29 May 2023 23:51:02 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Liao, Chang" <liaochang1@...wei.com>,
Shanker Donthineni <sdonthineni@...dia.com>,
Marc Zyngier <maz@...nel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Michael Walle <michael@...le.cc>, linux-kernel@...r.kernel.org,
Vikram Sethi <vsethi@...dia.com>,
Jason Sequeira <jsequeira@...dia.com>
Subject: Re: [PATCH v5 1/3] genirq: Use hlist for managing resend handlers
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
Powered by blists - more mailing lists