[Top] [All Lists]

Re: Lmbench results for Linux/MIPS 2.1.90

To: "William J. Earl" <>
Subject: Re: Lmbench results for Linux/MIPS 2.1.90
Date: Sun, 5 Apr 1998 12:06:02 +0200
In-reply-to: <>; from William J. Earl on Sun, Mar 22, 1998 at 09:30:05PM -0800
References: <> <>
On Sun, Mar 22, 1998 at 09:30:05PM -0800, William J. Earl wrote:

>  > I'm thinking about not saving the temporary registers on syscall entry;
>  > I'm just not shure if this would break the semantics of ptrace(2).
> ...
>       UMIPS-BSD (4.3 BSD on the MIPS M/1000) did not save the temporary
> registers on syscall().  It did, of course, save them on interrupts,
> so preemption left the registers valid.  I don't see why saving the
> registers on syscall should affect ptrace(), since the ptrace()
> caller is acting on another process, which will have saved all its
> registers if preempted.  That change ought to let the R5000 beat
> the Pentium, despite the Indy's miserable memory latency.

That's implemented now.  I'm also pulling another trick.  Why the hell
should be save all the s-registers during system calls?  The MIPS calling
sequence guarantees to us that they will not be destroyed.  Whoops,
another 150us or so.  It's what brought us down to 861ns, faster than
big bad Pentium from Borg.  All that it takes is adding some extra code;
sys_fork(), sys_clone() and do_signal expect the s-registers to be in
the stackframe, so I save them only in these routines.

I'm thinking about changing the calling sequence of syscalls as well.
When we get more than four arguments passed, we have to dig them out of
the userstack.  While this is fast on Linux we still need time for the
safety checks.  The t registers which are being clobbered anyway would
be sooo nice to pass them.

(Hey people, remember I told ya static linking is evil?  That change would
fry all your binaries ...  still time to relink :-)


<Prev in Thread] Current Thread [Next in Thread>