[PATCH] s390: optimize syscall function

[PATCH] s390: optimize syscall function

[Christian Borntraeger]

Since kernel 2.6.0 all Linux version accept the system call number
in register 1 for svc 0. There is no need to have special handling
that uses EX for system calls < 256. This will simplify and speed
up that code.

A microbenchmark doing "syscall(__NR_getpid);" in a loops gets faster
by ~12%.

        * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Simplify
        code by always using SVC 0 instead of EX.
        * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Likewise.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 sysdeps/unix/sysv/linux/s390/s390-32/syscall.S |   12 +++---------
 sysdeps/unix/sysv/linux/s390/s390-64/syscall.S |   12 +++---------
 2 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/sysdeps/unix/sysv/linux/s390/s390-32/syscall.S b/sysdeps/unix/sysv/linux/s390/s390-32/syscall.S
index 8506db1..0fa08cd 100644
--- a/sysdeps/unix/sysv/linux/s390/s390-32/syscall.S
+++ b/sysdeps/unix/sysv/linux/s390/s390-32/syscall.S
@@ -49,19 +49,13 @@ ENTRY (syscall)
 	l      %r6,192(%r15)       /* fifth parameter  */
 	l      %r7,196(%r15)       /* sixth parameter  */
 
-	basr   %r8,0
-0:	cl     %r1,4f-0b(%r8)      /* svc number < 256? */
-	jl     2f
-1:	svc    0
-	j      3f
-2:	ex     %r1,1b-0b(%r8)      /* lsb of R1 is subsituted as SVC number */
-3:	l      %r15,0(%r15)        /* load back chain */
+	svc    0
+	l      %r15,0(%r15)        /* load back chain.  */
 	cfi_adjust_cfa_offset (-96)
-	lm     %r6,15,24(%r15)     /* load registers */
+	lm     %r6,%r15,24(%r15)   /* load registers.  */
 
 	lhi    %r0,-4095
 	clr    %r2,%r0             /* check R2 for error */
 	jnl    SYSCALL_ERROR_LABEL
 	br     %r14                /* return to caller */
-4:	.long  256
 PSEUDO_END (syscall)
diff --git a/sysdeps/unix/sysv/linux/s390/s390-64/syscall.S b/sysdeps/unix/sysv/linux/s390/s390-64/syscall.S
index 24c47cb..466f27a 100644
--- a/sysdeps/unix/sysv/linux/s390/s390-64/syscall.S
+++ b/sysdeps/unix/sysv/linux/s390/s390-64/syscall.S
@@ -49,20 +49,14 @@ ENTRY (syscall)
 	lg     %r6,320(%r15)	   /* Fifth parameter.	*/
 	lg     %r7,328(%r15)	   /* Sixth parameter.	*/
 
-	basr   %r8,0
-0:	clg    %r1,4f-0b(%r8)      /* svc number < 256? */
-	jl     2f
-1:	svc    0
-	j      3f
-2:	ex     %r1,1b-0b(%r8)      /* lsb of R1 is subsituted as SVC number */
-3:	lg     %r15,0(%r15)        /* load back chain */
+	svc    0
+	lg     %r15,0(%r15)        /* load back chain.  */
 	cfi_adjust_cfa_offset (-160)
-	lmg	%r6,15,48(%r15)	   /* Load registers.  */
+	lmg	%r6,%r15,48(%r15)  /* Load registers.  */
 
 	lghi   %r0,-4095
 	clgr   %r2,%r0		   /* Check R2 for error.  */
 	jgnl   SYSCALL_ERROR_LABEL
 	br     %r14		   /* Return to caller.	 */
-4:	.quad  256
 PSEUDO_END (syscall)
 
-- 
1.7.1

Re: [PATCH] s390: optimize syscall function

[Martin Schwidefsky]

On Fri,  9 Jun 2017 13:29:07 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> Since kernel 2.6.0 all Linux version accept the system call number
> in register 1 for svc 0. There is no need to have special handling
> that uses EX for system calls < 256. This will simplify and speed
> up that code.
> 
> A microbenchmark doing "syscall(__NR_getpid);" in a loops gets faster
> by ~12%.
> 
>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Simplify
>         code by always using SVC 0 instead of EX.
>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Likewise.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  sysdeps/unix/sysv/linux/s390/s390-32/syscall.S |   12 +++---------
>  sysdeps/unix/sysv/linux/s390/s390-64/syscall.S |   12 +++---------
>  2 files changed, 6 insertions(+), 18 deletions(-)

NAK. E.g. this from glibc:

sysdeps/unix/sysv/linux/s390/s390-64:

ENTRY (syscall)
	...
        basr   %r8,0
0:      clg    %r1,4f-0b(%r8)      /* svc number < 256? */
        jl     2f
1:      svc    0
        j      3f
2:      ex     %r1,1b-0b(%r8)      /* lsb of R1 is subsituted as SVC number */
3:      lg     %r15,0(%r15)        /* load back chain */
        cfi_adjust_cfa_offset (-160)
        lmg     %r6,15,48(%r15)    /* Load registers.  */
	...

And there are old version of glibc where NR_syscalls was < 256 that
exclusively used the SVC instruction with the system call number
encoded in the instruction itself.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH] s390: optimize syscall function

[Adhemerval Zanella]

On 12/06/2017 02:49, Martin Schwidefsky wrote:
> On Fri,  9 Jun 2017 13:29:07 +0200
> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> 
>> Since kernel 2.6.0 all Linux version accept the system call number
>> in register 1 for svc 0. There is no need to have special handling
>> that uses EX for system calls < 256. This will simplify and speed
>> up that code.
>>
>> A microbenchmark doing "syscall(__NR_getpid);" in a loops gets faster
>> by ~12%.
>>
>>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Simplify
>>         code by always using SVC 0 instead of EX.
>>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Likewise.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  sysdeps/unix/sysv/linux/s390/s390-32/syscall.S |   12 +++---------
>>  sysdeps/unix/sysv/linux/s390/s390-64/syscall.S |   12 +++---------
>>  2 files changed, 6 insertions(+), 18 deletions(-)
> 
> NAK. E.g. this from glibc:
> 
> sysdeps/unix/sysv/linux/s390/s390-64:
> 
> ENTRY (syscall)
> 	...
>         basr   %r8,0
> 0:      clg    %r1,4f-0b(%r8)      /* svc number < 256? */
>         jl     2f
> 1:      svc    0
>         j      3f
> 2:      ex     %r1,1b-0b(%r8)      /* lsb of R1 is subsituted as SVC number */
> 3:      lg     %r15,0(%r15)        /* load back chain */
>         cfi_adjust_cfa_offset (-160)
>         lmg     %r6,15,48(%r15)    /* Load registers.  */
> 	...
> 
> And there are old version of glibc where NR_syscalls was < 256 that
> exclusively used the SVC instruction with the system call number
> encoded in the instruction itself.
> 

I am not following the NAK, is the 'svc' way not really allowed for current
minimum kernel supported for s390 (3.2) or is the 'svc' method not really the 
fastest one for such syscalls?

Re: [PATCH] s390: optimize syscall function

[Zack Weinberg]

On Mon, Jun 12, 2017 at 1:49 AM, Martin Schwidefsky
<schwidefsky@de.ibm.com> wrote:
> On Fri,  9 Jun 2017 13:29:07 +0200
> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>
>> Since kernel 2.6.0 all Linux version accept the system call number
>> in register 1 for svc 0. There is no need to have special handling
>> that uses EX for system calls < 256. This will simplify and speed
>> up that code.
>>
>> A microbenchmark doing "syscall(__NR_getpid);" in a loops gets faster
>> by ~12%.
>>
>>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Simplify
>>         code by always using SVC 0 instead of EX.
>>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Likewise.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  sysdeps/unix/sysv/linux/s390/s390-32/syscall.S |   12 +++---------
>>  sysdeps/unix/sysv/linux/s390/s390-64/syscall.S |   12 +++---------
>>  2 files changed, 6 insertions(+), 18 deletions(-)
>
> NAK. E.g. this from glibc:
>
> sysdeps/unix/sysv/linux/s390/s390-64:

Uh, I believe Christian was proposing to change the exact code you are
quoting.  Did you think he was proposing to remove backward
compatibility for EX from the kernel-side syscall path?

zw

Re: [PATCH] s390: optimize syscall function

[Martin Schwidefsky]

On Mon, 12 Jun 2017 09:04:36 -0300
Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:

> On 12/06/2017 02:49, Martin Schwidefsky wrote:
> > On Fri,  9 Jun 2017 13:29:07 +0200
> > Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> >   
> >> Since kernel 2.6.0 all Linux version accept the system call number
> >> in register 1 for svc 0. There is no need to have special handling
> >> that uses EX for system calls < 256. This will simplify and speed
> >> up that code.
> >>
> >> A microbenchmark doing "syscall(__NR_getpid);" in a loops gets faster
> >> by ~12%.
> >>
> >>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Simplify
> >>         code by always using SVC 0 instead of EX.
> >>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Likewise.
> >>
> >> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> >> ---
> >>  sysdeps/unix/sysv/linux/s390/s390-32/syscall.S |   12 +++---------
> >>  sysdeps/unix/sysv/linux/s390/s390-64/syscall.S |   12 +++---------
> >>  2 files changed, 6 insertions(+), 18 deletions(-)  
> > 
> > NAK. E.g. this from glibc:
> > 
> > sysdeps/unix/sysv/linux/s390/s390-64:
> > 
> > ENTRY (syscall)
> > 	...
> >         basr   %r8,0
> > 0:      clg    %r1,4f-0b(%r8)      /* svc number < 256? */
> >         jl     2f
> > 1:      svc    0
> >         j      3f
> > 2:      ex     %r1,1b-0b(%r8)      /* lsb of R1 is subsituted as SVC number */
> > 3:      lg     %r15,0(%r15)        /* load back chain */
> >         cfi_adjust_cfa_offset (-160)
> >         lmg     %r6,15,48(%r15)    /* Load registers.  */
> > 	...
> > 
> > And there are old version of glibc where NR_syscalls was < 256 that
> > exclusively used the SVC instruction with the system call number
> > encoded in the instruction itself.
> >   
> 
> I am not following the NAK, is the 'svc' way not really allowed for current
> minimum kernel supported for s390 (3.2) or is the 'svc' method not really the 
> fastest one for such syscalls?

I claim lack of coffee after the long weekend ..

Yes, with version 3.2 as the minimum kernel level for using a glibc with
the prosed patch everything should be fine. The support for system calls
larger than 256 has been added with 2.5.68.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH] s390: optimize syscall function

[Martin Schwidefsky]

On Mon, 12 Jun 2017 08:06:36 -0400
Zack Weinberg <zackw@panix.com> wrote:

> On Mon, Jun 12, 2017 at 1:49 AM, Martin Schwidefsky
> <schwidefsky@de.ibm.com> wrote:
> > On Fri,  9 Jun 2017 13:29:07 +0200
> > Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> >  
> >> Since kernel 2.6.0 all Linux version accept the system call number
> >> in register 1 for svc 0. There is no need to have special handling
> >> that uses EX for system calls < 256. This will simplify and speed
> >> up that code.
> >>
> >> A microbenchmark doing "syscall(__NR_getpid);" in a loops gets faster
> >> by ~12%.
> >>
> >>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Simplify
> >>         code by always using SVC 0 instead of EX.
> >>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Likewise.
> >>
> >> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> >> ---
> >>  sysdeps/unix/sysv/linux/s390/s390-32/syscall.S |   12 +++---------
> >>  sysdeps/unix/sysv/linux/s390/s390-64/syscall.S |   12 +++---------
> >>  2 files changed, 6 insertions(+), 18 deletions(-)  
> >
> > NAK. E.g. this from glibc:
> >
> > sysdeps/unix/sysv/linux/s390/s390-64:  
> 
> Uh, I believe Christian was proposing to change the exact code you are
> quoting.  Did you think he was proposing to remove backward
> compatibility for EX from the kernel-side syscall path?

Indeed, I was thinking too much about the kernel side of things. 

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH] s390: optimize syscall function

[Adhemerval Zanella]

On 12/06/2017 10:55, Martin Schwidefsky wrote:
> On Mon, 12 Jun 2017 09:04:36 -0300
> Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
> 
>> On 12/06/2017 02:49, Martin Schwidefsky wrote:
>>> On Fri,  9 Jun 2017 13:29:07 +0200
>>> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>>>   
>>>> Since kernel 2.6.0 all Linux version accept the system call number
>>>> in register 1 for svc 0. There is no need to have special handling
>>>> that uses EX for system calls < 256. This will simplify and speed
>>>> up that code.
>>>>
>>>> A microbenchmark doing "syscall(__NR_getpid);" in a loops gets faster
>>>> by ~12%.
>>>>
>>>>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Simplify
>>>>         code by always using SVC 0 instead of EX.
>>>>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Likewise.
>>>>
>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>> ---
>>>>  sysdeps/unix/sysv/linux/s390/s390-32/syscall.S |   12 +++---------
>>>>  sysdeps/unix/sysv/linux/s390/s390-64/syscall.S |   12 +++---------
>>>>  2 files changed, 6 insertions(+), 18 deletions(-)  
>>>
>>> NAK. E.g. this from glibc:
>>>
>>> sysdeps/unix/sysv/linux/s390/s390-64:
>>>
>>> ENTRY (syscall)
>>> 	...
>>>         basr   %r8,0
>>> 0:      clg    %r1,4f-0b(%r8)      /* svc number < 256? */
>>>         jl     2f
>>> 1:      svc    0
>>>         j      3f
>>> 2:      ex     %r1,1b-0b(%r8)      /* lsb of R1 is subsituted as SVC number */
>>> 3:      lg     %r15,0(%r15)        /* load back chain */
>>>         cfi_adjust_cfa_offset (-160)
>>>         lmg     %r6,15,48(%r15)    /* Load registers.  */
>>> 	...
>>>
>>> And there are old version of glibc where NR_syscalls was < 256 that
>>> exclusively used the SVC instruction with the system call number
>>> encoded in the instruction itself.
>>>   
>>
>> I am not following the NAK, is the 'svc' way not really allowed for current
>> minimum kernel supported for s390 (3.2) or is the 'svc' method not really the 
>> fastest one for such syscalls?
> 
> I claim lack of coffee after the long weekend ..
> 
> Yes, with version 3.2 as the minimum kernel level for using a glibc with
> the prosed patch everything should be fine. The support for system calls
> larger than 256 has been added with 2.5.68.

Thanks, since it should be ok we can also cleanup the {INLINE,INTERNAL}_SYSCALL
macros in s390x sysdep.h as well.

Re: [PATCH] s390: optimize syscall function

[Martin Schwidefsky]

On Tue, 13 Jun 2017 11:31:09 -0300
Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:

> On 12/06/2017 10:55, Martin Schwidefsky wrote:
> > On Mon, 12 Jun 2017 09:04:36 -0300
> > Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
> >   
> >> On 12/06/2017 02:49, Martin Schwidefsky wrote:  
> >>> On Fri,  9 Jun 2017 13:29:07 +0200
> >>> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> >>>     
> >>>> Since kernel 2.6.0 all Linux version accept the system call number
> >>>> in register 1 for svc 0. There is no need to have special handling
> >>>> that uses EX for system calls < 256. This will simplify and speed
> >>>> up that code.
> >>>>
> >>>> A microbenchmark doing "syscall(__NR_getpid);" in a loops gets faster
> >>>> by ~12%.
> >>>>
> >>>>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Simplify
> >>>>         code by always using SVC 0 instead of EX.
> >>>>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Likewise.
> >>>>
> >>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> >>>> ---
> >>>>  sysdeps/unix/sysv/linux/s390/s390-32/syscall.S |   12 +++---------
> >>>>  sysdeps/unix/sysv/linux/s390/s390-64/syscall.S |   12 +++---------
> >>>>  2 files changed, 6 insertions(+), 18 deletions(-)    
> >>>
> >>> NAK. E.g. this from glibc:
> >>>
> >>> sysdeps/unix/sysv/linux/s390/s390-64:
> >>>
> >>> ENTRY (syscall)
> >>> 	...
> >>>         basr   %r8,0
> >>> 0:      clg    %r1,4f-0b(%r8)      /* svc number < 256? */
> >>>         jl     2f
> >>> 1:      svc    0
> >>>         j      3f
> >>> 2:      ex     %r1,1b-0b(%r8)      /* lsb of R1 is subsituted as SVC number */
> >>> 3:      lg     %r15,0(%r15)        /* load back chain */
> >>>         cfi_adjust_cfa_offset (-160)
> >>>         lmg     %r6,15,48(%r15)    /* Load registers.  */
> >>> 	...
> >>>
> >>> And there are old version of glibc where NR_syscalls was < 256 that
> >>> exclusively used the SVC instruction with the system call number
> >>> encoded in the instruction itself.
> >>>     
> >>
> >> I am not following the NAK, is the 'svc' way not really allowed for current
> >> minimum kernel supported for s390 (3.2) or is the 'svc' method not really the 
> >> fastest one for such syscalls?  
> > 
> > I claim lack of coffee after the long weekend ..
> > 
> > Yes, with version 3.2 as the minimum kernel level for using a glibc with
> > the prosed patch everything should be fine. The support for system calls
> > larger than 256 has been added with 2.5.68.  
> 
> Thanks, since it should be ok we can also cleanup the {INLINE,INTERNAL}_SYSCALL
> macros in s390x sysdep.h as well.

How so? If you have a fixed system call number smaller than 256 the best option
is to encode the system call number in the instruction. Loading the number to
%r1 and then doing SVC-0 requires an additional instruction, no?

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH] s390: optimize syscall function

[Adhemerval Zanella]

> On 13 Jun 2017, at 13:01, Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
> 
> On Tue, 13 Jun 2017 11:31:09 -0300
> Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
> 
>>> On 12/06/2017 10:55, Martin Schwidefsky wrote:
>>> On Mon, 12 Jun 2017 09:04:36 -0300
>>> Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
>>> 
>>>>> On 12/06/2017 02:49, Martin Schwidefsky wrote:  
>>>>> On Fri,  9 Jun 2017 13:29:07 +0200
>>>>> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>>>>> 
>>>>>> Since kernel 2.6.0 all Linux version accept the system call number
>>>>>> in register 1 for svc 0. There is no need to have special handling
>>>>>> that uses EX for system calls < 256. This will simplify and speed
>>>>>> up that code.
>>>>>> 
>>>>>> A microbenchmark doing "syscall(__NR_getpid);" in a loops gets faster
>>>>>> by ~12%.
>>>>>> 
>>>>>>        * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Simplify
>>>>>>        code by always using SVC 0 instead of EX.
>>>>>>        * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Likewise.
>>>>>> 
>>>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>>>> ---
>>>>>> sysdeps/unix/sysv/linux/s390/s390-32/syscall.S |   12 +++---------
>>>>>> sysdeps/unix/sysv/linux/s390/s390-64/syscall.S |   12 +++---------
>>>>>> 2 files changed, 6 insertions(+), 18 deletions(-)    
>>>>> 
>>>>> NAK. E.g. this from glibc:
>>>>> 
>>>>> sysdeps/unix/sysv/linux/s390/s390-64:
>>>>> 
>>>>> ENTRY (syscall)
>>>>>    ...
>>>>>        basr   %r8,0
>>>>> 0:      clg    %r1,4f-0b(%r8)      /* svc number < 256? */
>>>>>        jl     2f
>>>>> 1:      svc    0
>>>>>        j      3f
>>>>> 2:      ex     %r1,1b-0b(%r8)      /* lsb of R1 is subsituted as SVC number */
>>>>> 3:      lg     %r15,0(%r15)        /* load back chain */
>>>>>        cfi_adjust_cfa_offset (-160)
>>>>>        lmg     %r6,15,48(%r15)    /* Load registers.  */
>>>>>    ...
>>>>> 
>>>>> And there are old version of glibc where NR_syscalls was < 256 that
>>>>> exclusively used the SVC instruction with the system call number
>>>>> encoded in the instruction itself.
>>>>> 
>>>> 
>>>> I am not following the NAK, is the 'svc' way not really allowed for current
>>>> minimum kernel supported for s390 (3.2) or is the 'svc' method not really the 
>>>> fastest one for such syscalls?  
>>> 
>>> I claim lack of coffee after the long weekend ..
>>> 
>>> Yes, with version 3.2 as the minimum kernel level for using a glibc with
>>> the prosed patch everything should be fine. The support for system calls
>>> larger than 256 has been added with 2.5.68.  
>> 
>> Thanks, since it should be ok we can also cleanup the {INLINE,INTERNAL}_SYSCALL
>> macros in s390x sysdep.h as well.
> 
> How so? If you have a fixed system call number smaller than 256 the best option
> is to encode the system call number in the instruction. Loading the number to
> %r1 and then doing SVC-0 requires an additional instruction, no?

Indeed, I had the wrong assumption the syscall.S method was used in sysdep.h.

Re: [PATCH] s390: optimize syscall function

[Christian Borntraeger]

On 06/12/2017 03:57 PM, Martin Schwidefsky wrote:
> On Mon, 12 Jun 2017 08:06:36 -0400
> Zack Weinberg <zackw@panix.com> wrote:
> 
>> On Mon, Jun 12, 2017 at 1:49 AM, Martin Schwidefsky
>> <schwidefsky@de.ibm.com> wrote:
>>> On Fri,  9 Jun 2017 13:29:07 +0200
>>> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>>>  
>>>> Since kernel 2.6.0 all Linux version accept the system call number
>>>> in register 1 for svc 0. There is no need to have special handling
>>>> that uses EX for system calls < 256. This will simplify and speed
>>>> up that code.
>>>>
>>>> A microbenchmark doing "syscall(__NR_getpid);" in a loops gets faster
>>>> by ~12%.
>>>>
>>>>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Simplify
>>>>         code by always using SVC 0 instead of EX.
>>>>         * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Likewise.
>>>>
>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>> ---
>>>>  sysdeps/unix/sysv/linux/s390/s390-32/syscall.S |   12 +++---------
>>>>  sysdeps/unix/sysv/linux/s390/s390-64/syscall.S |   12 +++---------
>>>>  2 files changed, 6 insertions(+), 18 deletions(-)  
>>>
>>> NAK. E.g. this from glibc:
>>>
>>> sysdeps/unix/sysv/linux/s390/s390-64:  
>>
>> Uh, I believe Christian was proposing to change the exact code you are
>> quoting.  Did you think he was proposing to remove backward
>> compatibility for EX from the kernel-side syscall path?

Exactly, this is a glibc patch :-)
The mimimum kernel version for glibc is high enough, so that the kernel 
will always understand svc 0, which allows us to get rid of ex in glibc
for svc.



> 
> Indeed, I was thinking too much about the kernel side of things. 

Re: [PATCH] s390: optimize syscall function

[Stefan Liebler]

On 06/19/2017 09:03 AM, Christian Borntraeger wrote:
> On 06/12/2017 03:57 PM, Martin Schwidefsky wrote:
>> On Mon, 12 Jun 2017 08:06:36 -0400
>> Zack Weinberg <zackw@panix.com> wrote:
>>
>>> On Mon, Jun 12, 2017 at 1:49 AM, Martin Schwidefsky
>>> <schwidefsky@de.ibm.com> wrote:
>>>> On Fri,  9 Jun 2017 13:29:07 +0200
>>>> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>>>>   
>>>>> Since kernel 2.6.0 all Linux version accept the system call number
>>>>> in register 1 for svc 0. There is no need to have special handling
>>>>> that uses EX for system calls < 256. This will simplify and speed
>>>>> up that code.
>>>>>
>>>>> A microbenchmark doing "syscall(__NR_getpid);" in a loops gets faster
>>>>> by ~12%.
>>>>>
>>>>>          * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Simplify
>>>>>          code by always using SVC 0 instead of EX.
>>>>>          * sysdeps/unix/sysv/linux/s390/s390-64/syscall.S: Likewise.
>>>>>
>>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>>> ---
>>>>>   sysdeps/unix/sysv/linux/s390/s390-32/syscall.S |   12 +++---------
>>>>>   sysdeps/unix/sysv/linux/s390/s390-64/syscall.S |   12 +++---------
>>>>>   2 files changed, 6 insertions(+), 18 deletions(-)
>>>>
>>>> NAK. E.g. this from glibc:
>>>>
>>>> sysdeps/unix/sysv/linux/s390/s390-64:
>>>
>>> Uh, I believe Christian was proposing to change the exact code you are
>>> quoting.  Did you think he was proposing to remove backward
>>> compatibility for EX from the kernel-side syscall path?
> 
> Exactly, this is a glibc patch :-)
> The mimimum kernel version for glibc is high enough, so that the kernel
> will always understand svc 0, which allows us to get rid of ex in glibc
> for svc.
> 
> 
> 
>>
>> Indeed, I was thinking too much about the kernel side of things.
> 
> 
> 

This patch is okay.
Committed.

Thanks.
Stefan