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

Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration

To: Jun Sun <jsun@mvista.com>
Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Fri, 1 Jun 2001 13:55:12 +0200 (MET DST)
Cc: Andreas Jaeger <aj@suse.de>, linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle <ralf@uni-koblenz.de>
In-reply-to: <3B1697BE.3F3765A2@mvista.com>
Organization: Technical University of Gdansk
Reply-to: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
On Thu, 31 May 2001, Jun Sun wrote:

> > This way you get the fast one if you configure glibc with
> > --enable-kernel=2.4.6 if we assume that 2.4.6 is the first kernel with
> > those features.
> >
> > Check other places in glibc for details how this can be done.
> 
> This might be an overkill - the slow code on a newer kernel costs about 1 or 2
> cycle longer per call.

 Do you realize how often the call is invoked!?  There is a number of
memory stores involved in the slow implementation -- with write-trough
cache it really sucks, even more than memory accesses in general. 

> On a second thought I feel stronger using $v1 is not a good idea - what if the
> return path of syscall suddenly needs to modify $v1?  Also we have generic
> syscall routine in glibc, what if someday that routine starts to check $v1 as
> well?

 We are safe here.  V1 is a result register so its semantics must be
preserved if at all possible.  Then there is the pipe() syscall that
already makes use of v1 as a result register for a long time, so we are
really, really safe. 

 There are t* registers available for the syscall handler if an additional
register is needed.  The coding conventions are there for a reason, aren't
they? 

> I understand the chances of these "what if" are low (and perhaps sys_pipe() is
> already this way), but I am still convinced we should the right thing. 
> (Whoever invented MIPS_ATOMIC_SET might have been thinking it should never
> need to return an error code!)

 Nope -- the problem lies elsewhere.  It is sysmips() that was invented to
return an error code and MIPS_ATOMIC_SET violating it from the day #1.  It
was plain broken since the beginning.  I suppose it ws just an ad hoc hack
written once someone realized the operation is necessary.  Just like the
whole sysmips() syscall. 

> I don't see any "dirtiness" in using the third argument.  The slowdown in
> performance should be negligible under the context of the whole system call.

 I do believe good performance is the main goal here.  The syscall is as
clean as possible -- it would still be possible to make it yet faster if
dirty hacks were added.

> A syscall is invented to be here and stay.  I personally feel more comfortable
> to play a little safer rather than a littel faster.

 Cycles sum up, unfortunately.  A strace of `ls -la' on my /usr/lib
directory shows about 4500 syscall invocations of which about 4000 are
invocations of _test_and_set()!

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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