Loading handle_arch_irq with a PC relative load

[Gilles Chanteperdrix]

On 07/13/2012 10:09 PM, Nicolas Pitre wrote:
> On Fri, 13 Jul 2012, Gilles Chanteperdrix wrote:
> 
>> On 07/13/2012 09:40 PM, Nicolas Pitre wrote:
>>> On Fri, 13 Jul 2012, Gilles Chanteperdrix wrote:
>>>
>>>>
>>>> I do not know if it is really useful, but it seems it would be possible 
>>>> to reduce the number of memory accesses to just one in the irq_handler 
>>>> macro in the case where CONFIG_MULTI_IRQ_HANDLER is enabled, by using a 
>>>> PC relative load, with something like the following patch:
>>>
>>> To be strict with ccode sections, you can't do this.  The 
>>> handle_arch_irq symbol identifies a variable and with your patch you're 
>>> moving it from the .data section to the .text section.  The .text 
>>> section is meant to be read only, and this is even more true when using 
>>> a XIP kernel where .text is in ROM, or if we could make the access 
>>> protection of the kernel ro.
>>
>> I understand that but, XIP kernel aside, the handle_arch_irq variable is
>> set only once very early during the boot process, so, almost read-only.
>> Is not Linux using self-modifying code in some cases anyway (booting an
>> SMP kernel on an UP processor for instance).
> 
> There are limits to which such tricks should be applied.  In the SMP on 
> UP case this is a matter of making the kernel boot at all which is a 
> rather strong reason.
> 
> Do you have performance numbers like interrupt latency that show this 
> patch being worth it?  Without concrete justifications I don't think we 
> should go down that path.

I intend to do some interrupt latency measurements soon. But I suspect
CONFIG_MULTI_IRQ_HANDLER will cause more differences due to the fact
that the irq handlers are now fat C compiled code instead of carefully
optimized assembly code, than because of these two memory accesses.

And in fact, chances are that I will observe nothing at all since the
low end platforms I have are AT91 which are not using
CONFIG_MULTI_IRQ_HANDLER yet.

-- 
                                                                Gilles.