On Wed, Jun 12, 2002 at 10:06:10AM -0400, Tom Lane wrote:
> rmurray@debian.org writes:
> > On Tue, Jun 11, 2002 at 02:05:34PM -0400, Tom Lane wrote:
> >> The s_lock change is in current sources, but it concerns me because it
> >> seems it could break other mips-based platforms (ie, pre-mips2). I'd
>
> > The Linux kernel will emulate ll/sc on mips1 platforms. If other kernels
> > won't/don't do this, then this should be made Linux/mips specific.
>
> That's exactly the answer I did *not* want to hear. The entire reason
> why we bother with TAS assembly coding is to avoid a trip to the kernel
> for low-level synchronization operations. If the existing s_lock coding
> incurs a protection fault and kernel emulation on MIPS1 machines, then
> it's worse than useless.
That's the only somewhat reliable way to do this on a MIPS1 machine. The
way it is done allows you to get full performance of a MIPS2 chip, and go
through the kernel on MIPS1, from the same binary. There is no other
somewhat reliable way to do TAS on MIPS1.
> add appropriate coding into the template files for all MIPS-capable
> platforms to select "-mips2" where appropriate. Thoughts? It's not
This penalizes people who want to build a binary that works everywhere, but
want the benefits of mips2 if it is available. At least for Linux/mips, I
think the best way is how it is currently. This certainly may not be the
case elsewhere.
> either the assembler directive or the compiler flag; can someone give
> exact details?
the assembler .set mips2 allows MIPS2 ISA opcodes to be used, but the
resulting binary will still be MIPS1. The compiler flag will produce a binary
that can only run on the MIPS2 ISA (and the last time I tried it, was not
usable at all on Linux/mips).
> > Prebuilt binaries provided by distributions like Debian often build for the
> > lowest common ISA that will work on all of the available hardware, so every
> > binary in the distribution is built for mips1, with the addition of ll/sc,
> > being emulated by the kernel, or done in hardware (if available)
>
> That is probably not going to be acceptable from a performance point of
> view. Note the comment in s_lock.h about 40% penalty for
> non-hardware-based spinlocks; if anything the number is probably worse
If performance is important, I doubt people will be using a MIPS1
platform without ll/sc. Any sane chip today, if it only complies with
MIPS1 tends to have ll/sc as well. It is this case of a mostly MIPS1 chip
that also implements ll/sc that can have the performance benefits of using
the opcodes passed along.
--
Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org)
The opinions expressed here are my own.