All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v4 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq()
Date: Wed, 4 Dec 2019 05:32:54 +0100	[thread overview]
Message-ID: <ebc67964-e5a9-acd0-0011-61ba23692f7e@c-s.fr> (raw)
In-Reply-To: <20191129184658.GR9491@gate.crashing.org>

Hi,

Le 29/11/2019 à 19:46, Segher Boessenkool a écrit :
> Hi!
> 
> On Wed, Nov 27, 2019 at 04:15:15PM +0100, Christophe Leroy wrote:
>> Le 27/11/2019 à 15:59, Segher Boessenkool a écrit :
>>> On Wed, Nov 27, 2019 at 02:50:30PM +0100, Christophe Leroy wrote:
>>>> So what do we do ? We just drop the "r2" clobber ?
>>>
>>> You have to make sure your asm code works for all ABIs.  This is quite
>>> involved if you do a call to an external function.  The compiler does
>>> *not* see this call, so you will have to make sure that all that the
>>> compiler and linker do will work, or prevent some of those things (say,
>>> inlining of the function containing the call).
>>
>> But the whole purpose of the patch is to inline the call to __do_irq()
>> in order to avoid the trampoline function.
> 
> Yes, so you call __do_irq.  You have to make sure that what you tell the
> compiler -- and what you *don't tell the compiler -- works with what the
> ABIs require, and what the called function expects and provides.
> 
>>> That does not fix everything.  The called function requires a specific
>>> value in r2 on entry.
>>
>> Euh ... but there is nothing like that when using existing
>> call_do_irq().
> 
>> How does GCC know that call_do_irq() has same TOC as __do_irq() ?
> 
> The existing call_do_irq isn't C code.  It doesn't do anything with r2,
> as far as I can see; __do_irq just gets whatever the caller of call_do_irq
> has.
> 
> So I guess all the callers of call_do_irq have the correct r2 value always
> already?  In that case everything Just Works.

Indeed, there is only one caller for call_do_irq() which is do_IRQ().
And do_IRQ() is also calling __do_irq() directly (when the stack pointer 
is already set to IRQ stack). do_IRQ() and __do_irq() are both in 
arch/powerpc/kernel/irq.c

As far as I can see when replacing the call to call_do_irq() by a call 
to __do_irq(), the compiler doesn't do anything special with r2, and 
doesn't add any nop after the bl either, whereas for all calls outside 
irq.c, there is a nop added. So I guess that's ok ?

Now that call_do_irq() is inlined, we can even define __do_irq() as static.

And that's the same for do_softirq_own_stack(), it is only called from 
do_softirq() which is defined in the same file as __do_softirq() 
(kernel/softirq.c)

Christophe

WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org, Paul Mackerras <paulus@samba.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq()
Date: Wed, 4 Dec 2019 05:32:54 +0100	[thread overview]
Message-ID: <ebc67964-e5a9-acd0-0011-61ba23692f7e@c-s.fr> (raw)
In-Reply-To: <20191129184658.GR9491@gate.crashing.org>

Hi,

Le 29/11/2019 à 19:46, Segher Boessenkool a écrit :
> Hi!
> 
> On Wed, Nov 27, 2019 at 04:15:15PM +0100, Christophe Leroy wrote:
>> Le 27/11/2019 à 15:59, Segher Boessenkool a écrit :
>>> On Wed, Nov 27, 2019 at 02:50:30PM +0100, Christophe Leroy wrote:
>>>> So what do we do ? We just drop the "r2" clobber ?
>>>
>>> You have to make sure your asm code works for all ABIs.  This is quite
>>> involved if you do a call to an external function.  The compiler does
>>> *not* see this call, so you will have to make sure that all that the
>>> compiler and linker do will work, or prevent some of those things (say,
>>> inlining of the function containing the call).
>>
>> But the whole purpose of the patch is to inline the call to __do_irq()
>> in order to avoid the trampoline function.
> 
> Yes, so you call __do_irq.  You have to make sure that what you tell the
> compiler -- and what you *don't tell the compiler -- works with what the
> ABIs require, and what the called function expects and provides.
> 
>>> That does not fix everything.  The called function requires a specific
>>> value in r2 on entry.
>>
>> Euh ... but there is nothing like that when using existing
>> call_do_irq().
> 
>> How does GCC know that call_do_irq() has same TOC as __do_irq() ?
> 
> The existing call_do_irq isn't C code.  It doesn't do anything with r2,
> as far as I can see; __do_irq just gets whatever the caller of call_do_irq
> has.
> 
> So I guess all the callers of call_do_irq have the correct r2 value always
> already?  In that case everything Just Works.

Indeed, there is only one caller for call_do_irq() which is do_IRQ().
And do_IRQ() is also calling __do_irq() directly (when the stack pointer 
is already set to IRQ stack). do_IRQ() and __do_irq() are both in 
arch/powerpc/kernel/irq.c

As far as I can see when replacing the call to call_do_irq() by a call 
to __do_irq(), the compiler doesn't do anything special with r2, and 
doesn't add any nop after the bl either, whereas for all calls outside 
irq.c, there is a nop added. So I guess that's ok ?

Now that call_do_irq() is inlined, we can even define __do_irq() as static.

And that's the same for do_softirq_own_stack(), it is only called from 
do_softirq() which is defined in the same file as __do_softirq() 
(kernel/softirq.c)

Christophe

  reply	other threads:[~2019-12-04  4:32 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10  5:36 [PATCH v4 1/2] powerpc/irq: bring back ksp_limit management in C functions Christophe Leroy
2019-10-10  5:36 ` Christophe Leroy
2019-10-10  5:36 ` [PATCH v4 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq() Christophe Leroy
2019-10-10  5:36   ` Christophe Leroy
2019-11-21  6:14   ` Michael Ellerman
2019-11-21  6:14     ` Michael Ellerman
2019-11-21 10:15     ` Segher Boessenkool
2019-11-21 10:15       ` Segher Boessenkool
2019-11-25 10:32       ` Michael Ellerman
2019-11-25 10:32         ` Michael Ellerman
2019-11-25 14:25         ` Segher Boessenkool
2019-11-25 14:25           ` Segher Boessenkool
2019-11-27 13:50           ` Christophe Leroy
2019-11-27 13:50             ` Christophe Leroy
2019-11-27 14:59             ` Segher Boessenkool
2019-11-27 14:59               ` Segher Boessenkool
2019-11-27 15:15               ` Christophe Leroy
2019-11-27 15:15                 ` Christophe Leroy
2019-11-29 18:46                 ` Segher Boessenkool
2019-11-29 18:46                   ` Segher Boessenkool
2019-12-04  4:32                   ` Christophe Leroy [this message]
2019-12-04  4:32                     ` Christophe Leroy
2019-12-06 20:59                     ` Segher Boessenkool
2019-12-06 20:59                       ` Segher Boessenkool
2019-12-07  9:42                       ` Christophe Leroy
2019-12-07  9:42                         ` Christophe Leroy
2019-12-07 17:40                         ` Segher Boessenkool
2019-12-07 17:40                           ` Segher Boessenkool
2019-12-09 10:53                           ` Michael Ellerman
2019-12-09 10:53                             ` Michael Ellerman
2019-12-19  6:57                             ` Christophe Leroy
2019-12-19  6:57                               ` Christophe Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ebc67964-e5a9-acd0-0011-61ba23692f7e@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.