Обсуждение: FIX: NetBSD/cobalt now compiles 7.2.1
Hi all, I've been messing with NetBSD/cobalt 1.5.3, and have found that the template file for NetBSD could be improved a little - without the following change the system dies in s_lock.c because the opcodes are only available with the -mips2 flag, and it's not correctly picked up for this platform. The file src/template/netbsd should have three lines added (similar to the current src/template/linux one), so the full file looks like this: ---- CFLAGS=-O2 case $host_cpu in cobalt*) CFLAGS="$CFLAGS -mips2";; esac ---- With this change made the standard 7.2.1 tarball compiled without a single problem. I've yet to test speed and stability. -- Ian Spray
Ian There was a patch submitted a while ago that doesn't seem to have been rolled into 7.2.1 that fixes this. It does it by patching s_lock.c to add the set .mips2 assembler directive. The patch is attached. Your patch works just as well. It is what I have been doing to get PostgreSQL to compile on the MIPS machine I am using. Cheers, Warwick > Hi all, > > I've been messing with NetBSD/cobalt 1.5.3, and have found that the template > file for NetBSD could be improved a little - without the following change > the system dies in s_lock.c because the opcodes are only available with the > -mips2 flag, and it's not correctly picked up for this platform. > > The file src/template/netbsd should have three lines added (similar to the > current src/template/linux one), so the full file looks like this: > > ---- > CFLAGS=-O2 > > case $host_cpu in > cobalt*) CFLAGS="$CFLAGS -mips2";; > esac > ---- > > With this change made the standard 7.2.1 tarball compiled without a single > problem. I've yet to test speed and stability. > -- Warwick Hunter Agile TV Corporation Voice: +61 7 5584 5912 Fax: +61 7 5575 9550 mailto:whunter@agile.tv http://www.agile.tv -----Forwarded Message----- From: rmurray@debian.org To: 139003@bugs.debian.org Cc: control@bugs.debian.org Subject: Bug#139003: a little bit more is needed... Date: 27 Mar 2002 00:21:18 -0800 reopen 139003 thanks Looks like a small patch is needed as well to do the right thing on Linux. The patch enables the mips2 ISA for the ll/sc operations, and then restores it when done. The kernel/libc emulation code will take over on CPUs without ll/sc, and on CPUs with it, it'll use the operations provided by the CPU. Combined with the earlier fix (removing -mips2), postgresql builds again on mips and mipsel. The patch is against 7.2-7. diff -urN postgresql-7.2/src/backend/storage/lmgr/s_lock.c postgresql-7.2.fixed/src/backend/storage/lmgr/s_lock.c --- postgresql-7.2/src/backend/storage/lmgr/s_lock.c Mon Nov 5 18:46:28 2001 +++ postgresql-7.2.fixed/src/backend/storage/lmgr/s_lock.c Wed Mar 27 07:46:59 2002 @@ -173,9 +173,12 @@ .global tas \n\ tas: \n\ .frame $sp, 0, $31 \n\ + .set push \n\ + .set mips2 \n\n ll $14, 0($4) \n\ or $15, $14, 1 \n\ sc $15, 0($4) \n\ + .set pop \n\ beq $15, 0, fail\n\ bne $14, 0, fail\n\ li $2, 0 \n\
Вложения
Warwick Hunter <whunter@agile.tv> writes:
> There was a patch submitted a while ago that doesn't
> seem to have been rolled into 7.2.1 that fixes this.
> It does it by patching s_lock.c to add the set .mips2
> assembler directive. The patch is attached.
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
vote for reverting that change and putting in Ian's template change
instead --- which for anyone not paying attention, was:
> The file src/template/netbsd should have three lines added (similar to the
> current src/template/linux one), so the full file looks like this:
>
> ----
> CFLAGS=-O2
>
> case $host_cpu in
> cobalt*) CFLAGS="$CFLAGS -mips2";;
> esac
> ----
Seems to me the template tweak would be a lot simpler to hack around on a
per-installation basis if needed.
Comments?
regards, tom lane
On Tue, Jun 11, 2002 at 02:05:34PM -0400, Tom Lane wrote: > Warwick Hunter <whunter@agile.tv> writes: > > There was a patch submitted a while ago that doesn't > > seem to have been rolled into 7.2.1 that fixes this. > > It does it by patching s_lock.c to add the set .mips2 > > assembler directive. The patch is attached. > > 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. > vote for reverting that change and putting in Ian's template change > instead --- which for anyone not paying attention, was: Please do _not_ revert the change. Making it linux specific would be fine, however. > Seems to me the template tweak would be a lot simpler to hack around on a > per-installation basis if needed. > > Comments? 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) -- Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org) The opinions expressed here are my own.
Вложения
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.
What I'm currently thinking is that we should undo the s_lock change and
add appropriate coding into the template files for all MIPS-capable
platforms to select "-mips2" where appropriate. Thoughts? It's not
real clear to me what the difference is that is actually created by
either the assembler directive or the compiler flag; can someone give
exact details?
> 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
today.
regards, tom lane
rmurray@debian.org writes:
> 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.
Hm. Okay, that's a fair argument. I'll leave it be ...
regards, tom lane
Tom Lane wrote: > rmurray@debian.org writes: > > 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. > > Hm. Okay, that's a fair argument. I'll leave it be ... OK, what did we decide on this change? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, what did we decide on this change?
I thought we'd decided that current CVS tip is okay. If the MIPS
camp wants to download it and verify ...
regards, tom lane
Tom, > I thought we'd decided that current CVS tip is okay. If the MIPS > camp wants to download it and verify ... The CVS tip of src/backend/lmgr/s_lock.c has the patch for "set .mips2" in it. Thanks, Warwick -- Warwick Hunter Agile TV Corporation Voice: +61 7 5584 5912 Fax: +61 7 5575 9550 mailto:whunter@agile.tv http://www.agile.tv
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.
Вложения
> I'll mark NetBSD/MIPS as supported. Or is there something > "cobalt-specific" about this which should have "cobalt" be the > architecture name? I am running PostgreSQL on Linux/MIPS, which is what the early Cobalts run rather than NetBSD. You could make the support statement more general than just NetBSD if you like. Warwick -- Warwick Hunter Agile TV Corporation Voice: +61 7 5584 5912 Fax: +61 7 5575 9550 mailto:whunter@agile.tv http://www.agile.tv
> > I thought we'd decided that current CVS tip is okay. If the MIPS
> > camp wants to download it and verify ...
> The CVS tip of src/backend/lmgr/s_lock.c has the
> patch for "set .mips2" in it.
I'll mark NetBSD/MIPS as supported. Or is there something
"cobalt-specific" about this which should have "cobalt" be the
architecture name?
- Thomas
...
> I am running PostgreSQL on Linux/MIPS, which is what the
> early Cobalts run rather than NetBSD. You could make
> the support statement more general than just NetBSD
> if you like.
OK, we already have an entry for Linux/MIPS with 7.2. We'll want to
update that for sure for the 7.3 release...
- Thomas