From: Theo Schlossnagle <jesus@omniti.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: josh.berkus@sun.com, robert.lor@sun.com, PostgreSQL-patches <pgsql-patches@postgresql.org>
Subject: Re: [BUGS] BUG #2401: spinlocks not available on amd64
Date: Thu, 27 Apr 2006 19:55:38 -0400
Message-ID: <445159FA.7070206@omniti.com> (raw)
In-Reply-To: <16483.1146178926@sss.pgh.pa.us>
References: <200604272231.k3RMVYM28488@candle.pha.pa.us>
<16483.1146178926@sss.pgh.pa.us>
Tom Lane wrote:
>Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
>
>>Great, changes attached and applied. I removed the solaris_i386 and
>>solaris_x86_64.s files and made just one solaris_x86.s. I updated the
>>build system to use the new file, updated the macros, and added some
>>documentation on the approach. Thanks.
>>
>>
>
>BTW, on the replacement of ldstub with cas: according to what I find in
>google, cas does not exist on pre-V9 SPARCs. Are we sure no one uses
>sparc v8 chips anymore? Is there any actual advantage to making that
>change?
>
>
This is true, and can be addressed with #defines to pull in the old old
code. Just to note, you can't run Solaris 10 or any future version of
Solaris on sparcv8 either. Sparcv8plus is 3bit sparc code and it does
support the cas operation. The instruction cas that operates on a word
is more much efficient than the code that it replaced. I'm don't own or
have access to any sparc machines old enough to have that issue (even on
my guest accounts at my alma mater). If this is a concern, it seems
more than reasonable to #elif the case in for that architecture in the
sparc assembly file -- being open source, you'll no doubt alienate some
dude who thinks its cool to run Postgres on his Sparc ELC.
I'd remind everyone that the spinlock stuff is entirely optional at
build time. I think it be more elegant approach to discontinue spinlock
support on sparcv8 and older sparc architectures and just force them to
use heavier weight locking mechanisms. I "accidentally" did this on my
Sol10 amd64 box before I realized what the build system did.
I also think it immensely useful to replace all of the tas subsystem
with cas so that one could reliabily lock these atomics with the process
id of the locker. This would allow extremely good diagnostics in the
event that a backend process is abruptly teminated while holding a log
on that shm segment. If the process ID was in there, it would then be a
contition that is both diagnosable and recoverable.
I could likely provide the cas bits and pieces to do this stuff on
linux/freebsd/mac os x and windows on x86/64 sparcv8plus/sparcv9 and PPC
if you think that would be useful.
Best regards,
Theo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: jesus@omniti.com, tgl@sss.pgh.pa.us, pgman@candle.pha.pa.us
Subject: Re: [BUGS] BUG #2401: spinlocks not available on amd64
In-Reply-To: <445159FA.7070206@omniti.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox