linux-mips-fnet
[Top] [All Lists]

Re: Lmbench results for Linux/MIPS 2.1.90

To: "William J. Earl" <wje@fir.engr.sgi.com>
Subject: Re: Lmbench results for Linux/MIPS 2.1.90
From: ralf@uni-koblenz.de
Date: Mon, 23 Mar 1998 06:55:16 +0100
Cc: linux-mips@fnet.fr, linux-mips@vger.rutgers.edu, linux@cthulhu.engr.sgi.com, lm@who.net
In-reply-to: <199803230530.VAA12819@fir.engr.sgi.com>; from William J. Earl on Sun, Mar 22, 1998 at 09:30:05PM -0800
References: <19980322075452.09681@uni-koblenz.de> <199803230530.VAA12819@fir.engr.sgi.com>
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.

Yeah, let's make some nice benchmarks that are going to fry the borg :-)
Given that we have that many registers I think we might reach the magic
1.0 microseconds.  It's just 56 cycles we need to get from somewhere ...

I was thinking about ptrace(2) because on Linux it has an option
(PF_TRACESYS) where the tracee is only stopped on syscalls.  Anyway, the
lost registers are just temporary registers, so away with 'em ...

  Ralf

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