From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <pg@heroku.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Cc: Ants Aasma <ants@cybertec.at>
Subject: Re: better atomics
Date: Wed, 16 Oct 2013 22:39:07 +0200
Message-ID: <7607.1381955947@sss.pgh.pa.us> (raw)
In-Reply-To: <20131016194541.GO5319@awork2.anarazel.de>
References: <CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com>
<20131016194541.GO5319@awork2.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-10-16 14:30:34 -0400, Robert Haas wrote:
>>> But _and, _or are really useful because they can be used to atomically
>>> clear and set flag bits.
>> Until we have some concrete application that requires this
>> functionality for adequate performance, I'd be inclined not to bother.
>> I think we have bigger fish to fry, and (to extend my nautical
>> metaphor) trying to get this working everywhere might amount to trying
>> to boil the ocean.
> Well, I actually have a very, very preliminary patch using them in the
> course of removing the spinlocks in PinBuffer() (via LockBufHdr()).
I think we need to be very, very wary of making our set of required
atomics any larger than it absolutely has to be. The more stuff we
require, the closer we're going to be to making PG a program that only
runs well on Intel. I am not comforted by the "gcc will provide good
implementations of the atomics everywhere" argument, because in fact
it won't. See for example the comment associated with our only existing
use of gcc atomics:
* On ARM, we use __sync_lock_test_and_set(int *, int) if available, and if
* not fall back on the SWPB instruction. SWPB does not work on ARMv6 or
* later, so the compiler builtin is preferred if available. Note also that
* the int-width variant of the builtin works on more chips than other widths.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That's not a track record that should inspire much faith that complete
sets of atomics will exist elsewhere. What's more, we don't just need
atomics that *work*, we need atomics that are *fast*, else the whole
exercise turns into pessimization not improvement. The more atomic ops
we depend on, the more likely it is that some of them will involve kernel
support on some chips, destroying whatever performance improvement we
hoped to get.
> ... The only thing I'd touch around platforms in that patch is
> adding a generic fallback pg_atomic_test_and_set() to s_lock.h and
> remove the special case usages of __sync_lock_test_and_set() (Arm64,
> some 32 bit arms).
Um, if we had a "generic" pg_atomic_test_and_set(), s_lock.h would be
about one line long. The above quote seems to me to be exactly the kind
of optimism that is not warranted in this area.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@2ndquadrant.com, robertmhaas@gmail.com, pg@heroku.com, ants@cybertec.at
Subject: Re: better atomics
In-Reply-To: <7607.1381955947@sss.pgh.pa.us>
* 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