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
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
> 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 W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: firstname.lastname@example.org, PGP key available +