From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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 - v0.5
Date: Mon, 30 Jun 2014 19:54:34 +0200
Message-ID: <20140630175434.GM21422@awork2.anarazel.de> (raw)
In-Reply-To: <11914.1404147250@sss.pgh.pa.us>
References: <20140626102006.GB1926@awork2.anarazel.de>
<CA+TgmoYUQ17UFfG3S-zctOdT9ba3cuW-J7TmfzKPF_N=nkqCEw@mail.gmail.com>
<54412.1403808435@sss.pgh.pa.us>
<20140626190405.GA21422@awork2.anarazel.de>
<CA+TgmoZjAiqjg40364uSkyh8c7iib_VbvsTDuwG2d-rX8p1BeA@mail.gmail.com>
<20140627180033.GF18288@awork2.anarazel.de>
<CA+TgmoZBnU7UcDRw1_Mgu3nW3RQ1OeSGecO_--Br7f5gz0GUrA@mail.gmail.com>
<20140628082559.GB6450@awork2.anarazel.de>
<CA+TgmoYd1BKsbvqPuCQuQb6+9znVLgjhJTvLo9tS=FuY1jXw0Q@mail.gmail.com>
<11914.1404147250@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2014-06-30 12:54:10 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > ... this again is my point: why can't we make the same argument about
> > two spinlocks situated on the same cache line? I don't have a bit of
> > trouble believing that doing the same thing with a couple of spinlocks
> > could sometimes work out well, too, but Tom is adamantly opposed to
> > that.
>
> I think you might be overstating my position here. What I'm concerned
> about is that we be sure that spinlocks are held for a sufficiently short
> time that it's very unlikely that we get pre-empted while holding one.
> I don't have any particular bright line about how short a time that is,
> but more than "a few instructions" worries me. As you say, the Linux
> kernel is a bad example to follow because it hasn't got a risk of losing
> its timeslice while holding a spinlock.
Well, they actually have preemptable and irq-interruptile versions for
some of these locks, but whatever :).
> So ISTM the question we ought to be asking is whether atomic operations
> have bounded execution time, or more generally what the distribution of
> execution times is likely to be. I'd be OK with an answer that includes
> "sometimes it can be long" so long as "sometimes" is "pretty damn
> seldom".
I think it ranges from 'never' to 'sometimes, but pretty darn
seldom'. Depending on the platform and emulation.
And, leaving the emulation and badly written code aside, there's no
issue with another backend sleeping while the atomic variable needs to
be modified.
> Spinlocks have a nonzero risk of taking a long time already, since we
> can't entirely prevent the possibility of losing our timeslice while
> holding one. The issue here is just to be sure that that happens seldom
> enough that it doesn't cause performance problems. If we fail to do that
> we might negate all the desired performance improvements from adopting
> atomic ops in the first place.
I think individual patches will have to stand up to a test like
this. Modifying a atomic variable inside a spinlock is only going to be
worth it if it allows to avoid spinlocks alltogether in 95%+ of the
time.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
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: andres@2ndquadrant.com, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, pg@heroku.com, ants@cybertec.at
Subject: Re: better atomics - v0.5
In-Reply-To: <20140630175434.GM21422@awork2.anarazel.de>
* 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