| Message ID | 1497007747-191015-1-git-send-email-borntraeger@de.ibm.com |
|---|---|
| State | New |
| Headers | show |
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.
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?
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
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.
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.
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.
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?
> 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.
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.
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
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)
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(-)