[PATCH -mm] i386 syscall opcode reordering (pipelining)

[PATCH -mm] i386 syscall opcode reordering (pipelining)

[Andreas Mohr]

Hi all,

I'd guess that this version features improved pipeline parallelism,
since we isolate competing %ebx accesses (_syscall4()) and
stack push operations (_syscall5()), right?

Signed-off-by: Andreas Mohr <andi@lisas.de>


diff -urN linux-2.6.17-rc6-mm2.orig/include/asm-i386/unistd.h linux-2.6.17-rc6-mm2.my/include/asm-i386/unistd.h
--- linux-2.6.17-rc6-mm2.orig/include/asm-i386/unistd.h	2006-06-13 19:28:15.000000000 +0200
+++ linux-2.6.17-rc6-mm2.my/include/asm-i386/unistd.h	2006-06-13 19:40:07.000000000 +0200
@@ -400,7 +400,7 @@
 type name (type1 arg1,type2 arg2,type3 arg3,type4 arg4,type5 arg5) \
 { \
 long __res; \
-__asm__ volatile ("push %%ebx ; movl %2,%%ebx ; movl %1,%%eax ; " \
+__asm__ volatile ("push %%ebx ; movl %1,%%eax ; movl %2,%%ebx ; " \
                   "int $0x80 ; pop %%ebx" \
 	: "=a" (__res) \
 	: "i" (__NR_##name),"ri" ((long)(arg1)),"c" ((long)(arg2)), \
@@ -415,8 +415,8 @@
 { \
 long __res; \
   struct { long __a1; long __a6; } __s = { (long)arg1, (long)arg6 }; \
-__asm__ volatile ("push %%ebp ; push %%ebx ; movl 4(%2),%%ebp ; " \
-                  "movl 0(%2),%%ebx ; movl %1,%%eax ; int $0x80 ; " \
+__asm__ volatile ("push %%ebp ; movl %1,%%eax ; push %%ebx ; " \
+                  "movl 4(%2),%%ebp ; movl 0(%2),%%ebx ; int $0x80 ; " \
                   "pop %%ebx ;  pop %%ebp" \
 	: "=a" (__res) \
 	: "i" (__NR_##name),"0" ((long)(&__s)),"c" ((long)(arg2)), \

Re: [PATCH -mm] i386 syscall opcode reordering (pipelining)

[Arjan van de Ven]

Andreas Mohr wrote:
> Hi all,
> 
> I'd guess that this version features improved pipeline parallelism,
> since we isolate competing %ebx accesses (_syscall4()) and
> stack push operations (_syscall5()), right?

is anybody actually EVER using those???
I would think not....

Re: [PATCH -mm] i386 syscall opcode reordering (pipelining)

[H. Peter Anvin]

Followup to:  <448F1B97.3070207@linux.intel.com>
By author:    Arjan van de Ven <arjan@linux.intel.com>
In newsgroup: linux.dev.kernel
>
> Andreas Mohr wrote:
> > Hi all,
> > 
> > I'd guess that this version features improved pipeline parallelism,
> > since we isolate competing %ebx accesses (_syscall4()) and
> > stack push operations (_syscall5()), right?
> 
> is anybody actually EVER using those???
> I would think not....

Probably not.  The _syscallN() macros are broken for the general case
on any 32-bit architecture, since they can't handle multiregister
arguments.

Similarly, a general syscall() function is broken (in the sense that
one would have to have syscall-specific code to mangle the arguments)
on *some*, but not all, 32-bit architectures, since some architectures
have alignment constraints on multiregister arguments, and the syscall
number argument throws off that alignment.

	-hpa

Re: [PATCH -mm] i386 syscall opcode reordering (pipelining)

[David Woodhouse]

On Tue, 2006-06-13 at 15:11 -0700, H. Peter Anvin wrote:
> > is anybody actually EVER using those???
> > I would think not....
> 
> Probably not.  The _syscallN() macros are broken for the general case
> on any 32-bit architecture, since they can't handle multiregister
> arguments.

In the -mm tree they're no longer visible outside ifdef __KERNEL__.

-- 
dwmw2

Re: [PATCH -mm] i386 syscall opcode reordering (pipelining)

[H. Peter Anvin]

Followup to:  <e6nd68$4sq$1@terminus.zytor.com>
By author:    "H. Peter Anvin" <hpa@zytor.com>
In newsgroup: linux.dev.kernel
> 
> Probably not.  The _syscallN() macros are broken for the general case
> on any 32-bit architecture, since they can't handle multiregister
> arguments.
> 
> Similarly, a general syscall() function is broken (in the sense that
> one would have to have syscall-specific code to mangle the arguments)
> on *some*, but not all, 32-bit architectures, since some architectures
> have alignment constraints on multiregister arguments, and the syscall
> number argument throws off that alignment.
> 

I should probably add that it is possible to write _syscallN() macros
that handle multiregister arguments correctly; just the current ones
aren't done correctly.  The complexity gets pretty staggering for the
higher argument counts, though, as for each _syscallN() you have to
support 2^N possible cases, just to deal with 32- and 64-bit arguments
(which is all we support at this point, so it'd be okay.)

	-hpa

Re: [PATCH -mm] i386 syscall opcode reordering (pipelining)

[Andreas Mohr]

Hi,

On Tue, Jun 13, 2006 at 01:09:59PM -0700, Arjan van de Ven wrote:
> Andreas Mohr wrote:
> >Hi all,
> >
> >I'd guess that this version features improved pipeline parallelism,
> >since we isolate competing %ebx accesses (_syscall4()) and
> >stack push operations (_syscall5()), right?
> 
> is anybody actually EVER using those???
> I would think not....

In that case... consider the patch dumped ;)

Andreas Mohr