Skip site navigation (1) Skip section navigation (2)

Re: FIX: NetBSD/cobalt now compiles 7.2.1

From: rmurray(at)debian(dot)org
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Warwick Hunter <whunter(at)agile(dot)tv>,Ian Spray <pgsql(at)borg(dot)minimal(dot)cx>, pgsql-ports(at)postgresql(dot)org,Oliver Elphick <olly(at)lfix(dot)co(dot)uk>
Subject: Re: FIX: NetBSD/cobalt now compiles 7.2.1
Date: 2002-06-13 18:24:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-ports
On Wed, Jun 12, 2002 at 10:06:10AM -0400, Tom Lane wrote:
> rmurray(at)debian(dot)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(at)cyberhqz(dot)com, rmurray(at)debian(dot)org)
The opinions expressed here are my own.

In response to


pgsql-ports by date

Next:From: Tom LaneDate: 2002-06-13 19:36:50
Subject: Re: FIX: NetBSD/cobalt now compiles 7.2.1
Previous:From: Tom LaneDate: 2002-06-12 14:06:10
Subject: Re: FIX: NetBSD/cobalt now compiles 7.2.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group