Hi Andres,
Are you planning to continue working on this? Summarizing the discussion
so far:
* Robert listed a bunch of little cleanup tasks
(http://www.postgresql.org/message-id/ca+tgmozshvvqjakul6p3kdvzvpibtgkzoti3m+fvvjg5v+x...@mail.gmail.com).
Amit posted yet more detailed commends.
*
Hi,
On 2014-08-20 12:43:05 +0300, Heikki Linnakangas wrote:
Are you planning to continue working on this?
Yes, I am! I've recently been on holiday and now I'm busy with catching
up with everything that has happened since. I hope to have a next
version ready early next week.
Greetings,
Andres
On Mon, Jul 14, 2014 at 12:47 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-07-08 11:51:14 +0530, Amit Kapila wrote:
On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
Further review of patch:
1.
/*
* pg_atomic_test_and_set_flag - TAS()
*
*
On 2014-07-10 08:46:55 +0530, Amit Kapila wrote:
As per my understanding of the general theory around barriers,
read and write are defined to avoid reordering due to compiler and
full memory barriers are defined to avoid reordering due to
processors.
No, that's not the case. There's several
Hi Amit,
On 2014-07-08 11:51:14 +0530, Amit Kapila wrote:
On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund and...@2ndquadrant.com
wrote:
Further review of patch:
1.
/*
* pg_atomic_test_and_set_flag - TAS()
*
On Thu, Jul 10, 2014 at 08:46:55AM +0530, Amit Kapila wrote:
As per my understanding of the general theory around barriers,
read and write are defined to avoid reordering due to compiler and
full memory barriers are defined to avoid reordering due to processors.
There are some processors that
On Sat, Jul 12, 2014 at 1:26 AM, Martijn van Oosterhout klep...@svana.org
wrote:
On Thu, Jul 10, 2014 at 08:46:55AM +0530, Amit Kapila wrote:
As per my understanding of the general theory around barriers,
read and write are defined to avoid reordering due to compiler and
full memory
On Tue, Jul 8, 2014 at 2:21 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund and...@2ndquadrant.com
wrote:
Further review of patch:
1.
/*
* pg_atomic_test_and_set_flag
On Wed, Jul 9, 2014 at 8:58 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 8, 2014 at 2:21 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
Further review of patch:
1.
/*
*
On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund and...@2ndquadrant.com
wrote:
Further review of patch:
1.
/*
* pg_atomic_test_and_set_flag - TAS()
*
* Acquire/read barrier semantics.
*/
STATIC_IF_INLINE_DECLARE bool
On Fri, Jun 27, 2014 at 9:00 PM, Andres Freund and...@2ndquadrant.com wrote:
Imagine the situation for the buffer header spinlock which is one of the
bigger performance issues atm. We could aim to replace all usages of
that with clever and complicated logic, but it's hard.
The IMO reasonable
On 2014-07-02 09:27:52 +0300, Ants Aasma wrote:
On Fri, Jun 27, 2014 at 9:00 PM, Andres Freund and...@2ndquadrant.com wrote:
Imagine the situation for the buffer header spinlock which is one of the
bigger performance issues atm. We could aim to replace all usages of
that with clever and
Hi,
On 2014-06-30 20:28:52 +0200, Andres Freund wrote:
To quantify this, on my 2 socket xeon E5520 workstation - which is too
small to heavily show the contention problems in pgbench -S - the
numbers are:
pgbench -M prepared -c 16 -j 16 -T 10 -S (best of 5, noticeably variability)
master:
On 2014-06-26 00:42:37 +0300, Heikki Linnakangas wrote:
On 06/25/2014 11:36 PM, Andres Freund wrote:
- I completely loathe the file layout you've proposed in
src/include/storage. If we're going to have separate #include files
for each architecture (and I'd rather we didn't go that route,
On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-07-01 10:44:19 +0530, Amit Kapila wrote:
I think defining barrier support for some atomic ops and not for others
will lead to inconsistency with specs and we need to additionally
define rules for such
On 2014-07-01 10:44:19 +0530, Amit Kapila wrote:
I think for such usage, we need to rely on barriers wherever there is a
need for synchronisation, recent example I have noticed is in your patch
where we have to use pg_write_barrier() during wakeup. However if we
go by atomic ops definition,
On 2014-06-30 11:04:53 +0530, Amit Kapila wrote:
On Sun, Jun 29, 2014 at 2:54 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-29 11:53:28 +0530, Amit Kapila wrote:
On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund and...@2ndquadrant.com
I think it is better to have some discussion
On Sat, Jun 28, 2014 at 4:25 AM, Andres Freund and...@2ndquadrant.com wrote:
To make pin/unpin et al safe without acquiring the spinlock the pincount
and the flags had to be moved into one variable so that when
incrementing the pincount you automatically get the flagbits back. If
it's
On 2014-06-30 12:15:06 -0400, Robert Haas wrote:
More broadly, it doesn't seem consistent. I think that other projects
also sometimes write code that acquires a spinlock while holding
another spinlock, and we don't do that; in fact, we've elevated that
to a principle, regardless of whether it
Robert Haas robertmh...@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
On Mon, Jun 30, 2014 at 12:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The existing coding rules also discourage spinlocking within a spinlock,
and the reason for that is that there's no very clear upper bound to the
time required to obtain a spinlock, so that there would also be no clear
upper
On 2014-06-30 13:15:23 -0400, Robert Haas wrote:
On Mon, Jun 30, 2014 at 12:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The existing coding rules also discourage spinlocking within a spinlock,
and the reason for that is that there's no very clear upper bound to the
time required to obtain a
Robert Haas robertmh...@gmail.com writes:
I'm personally not convinced that we're approaching this topic in the
right way. I'm not convinced that it's at all reasonable to try to
emulate atomics on platforms that don't have them. I would punt the
problem into the next layer and force things
On 2014-06-30 12:54:10 -0400, Tom Lane wrote:
Robert Haas robertmh...@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
On 2014-06-30 19:44:47 +0200, Andres Freund wrote:
On 2014-06-30 13:15:23 -0400, Robert Haas wrote:
People who write code that uses atomics are not
likely to think about how those algorithms will actually perform when
those atomics are merely emulated, and I suspect that means that in
On 2014-06-30 13:45:52 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I'm personally not convinced that we're approaching this topic in the
right way. I'm not convinced that it's at all reasonable to try to
emulate atomics on platforms that don't have them. I would punt
On Mon, Jun 30, 2014 at 07:44:47PM +0200, Andres Freund wrote:
On 2014-06-30 13:15:23 -0400, Robert Haas wrote:
I'm personally not convinced that we're approaching this topic in the
right way. I'm not convinced that it's at all reasonable to try to
emulate atomics on platforms that don't
On Mon, Jun 30, 2014 at 2:54 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-30 11:04:53 +0530, Amit Kapila wrote:
On Sun, Jun 29, 2014 at 2:54 PM, Andres Freund and...@2ndquadrant.com
wrote:
Yes, intentionally so. It's often important to get/set the current
value
without the
On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-28 11:58:41 +0530, Amit Kapila wrote:
1.
+pg_atomic_compare_exchange_u32_impl(volatile pg_atomic_uint32 *ptr,
+ uint32 *expected, uint32 newval)
+{
+ bool ret;
+ uint32 current;
+ current =
On 2014-06-29 11:53:28 +0530, Amit Kapila wrote:
On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund and...@2ndquadrant.com
Two things:
a) compare_exchange is a read/write operator and so far I've defined it
to have full barrier semantics (documented in atomics.h). I'd be
happy to
On 2014-06-28 19:36:39 +0300, Heikki Linnakangas wrote:
On 06/27/2014 08:15 PM, Robert Haas wrote:
On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund and...@2ndquadrant.com
wrote:
I don't really see usecases where it's not related data that's being
touched, but: The point is that the fastpath
On Sun, Jun 29, 2014 at 2:54 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-29 11:53:28 +0530, Amit Kapila wrote:
On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund and...@2ndquadrant.com
I think it is better to have some discussion about it. Apart from this,
today I noticed atomic
On Wed, Jun 25, 2014 at 10:44 PM, Andres Freund and...@2ndquadrant.com
wrote:
Attached is a new version of the atomic operations patch. Lots has
changed since the last post:
* gcc, msvc work. acc, xlc, sunpro have blindly written support which
should be relatively easy to fix up. All try
On 2014-06-28 11:58:41 +0530, Amit Kapila wrote:
On Wed, Jun 25, 2014 at 10:44 PM, Andres Freund and...@2ndquadrant.com
wrote:
Attached is a new version of the atomic operations patch. Lots has
changed since the last post:
* gcc, msvc work. acc, xlc, sunpro have blindly written support
On 2014-06-27 22:47:02 -0400, Robert Haas wrote:
On Fri, Jun 27, 2014 at 2:00 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-27 13:15:25 -0400, Robert Haas wrote:
On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund and...@2ndquadrant.com
wrote:
I don't really see usecases where
On 06/27/2014 08:15 PM, Robert Haas wrote:
On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund and...@2ndquadrant.com wrote:
I don't really see usecases where it's not related data that's being
touched, but: The point is that the fastpath (not using a spinlock) might
touch the atomic variable, even
On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund and...@2ndquadrant.com wrote:
I don't really see usecases where it's not related data that's being
touched, but: The point is that the fastpath (not using a spinlock) might
touch the atomic variable, even while the slowpath has acquired the
On 2014-06-27 13:15:25 -0400, Robert Haas wrote:
On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund and...@2ndquadrant.com wrote:
I don't really see usecases where it's not related data that's being
touched, but: The point is that the fastpath (not using a spinlock) might
touch the atomic
On Fri, Jun 27, 2014 at 2:00 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-27 13:15:25 -0400, Robert Haas wrote:
On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund and...@2ndquadrant.com
wrote:
I don't really see usecases where it's not related data that's being
touched, but: The
On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund and...@2ndquadrant.com wrote:
Since it better be legal to manipulate a atomic variable while holding a
spinlock we cannot simply use an arbitrary spinlock as backing for
atomics. That'd possibly
On 2014-06-25 20:22:31 -0400, Robert Haas wrote:
On Wed, Jun 25, 2014 at 5:42 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I think having a separate file for each architecture is nice. I totally
agree that they don't belong in src/include/storage, though. s_lock.h has
always been
On Thu, Jun 26, 2014 at 5:20 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund and...@2ndquadrant.com
wrote:
Since it better be legal to manipulate a atomic variable while holding a
spinlock we
On 2014-06-26 07:44:14 -0500, Merlin Moncure wrote:
On Thu, Jun 26, 2014 at 5:20 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund and...@2ndquadrant.com
wrote:
Since it better be legal to
On Thu, Jun 26, 2014 at 12:20:06PM +0200, Andres Freund wrote:
On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund and...@2ndquadrant.com
wrote:
Since it better be legal to manipulate a atomic variable while holding a
spinlock we cannot
On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund and...@2ndquadrant.com
wrote:
Since it better be legal to manipulate a atomic variable while holding a
spinlock we
On Thu, Jun 26, 2014 at 7:21 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-25 20:22:31 -0400, Robert Haas wrote:
On Wed, Jun 25, 2014 at 5:42 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I think having a separate file for each architecture is nice. I totally
agree that
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
I think that's going to fall afoul of Tom's previously-articulated no
loops inside spinlocks rule. Most atomics, by nature,
On 2014-06-26 11:47:15 -0700, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
I think that's going to fall afoul of Tom's previously-articulated no
On Thu, Jun 26, 2014 at 1:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Would it be practical to say that the coding rule is that you can only
use atomic ops on fields that are protected by the spinlock, ie, nobody
else is supposed to be touching those
On 06/25/2014 10:14 AM, Andres Freund wrote:
Hi,
[sorry for the second copy Robert]
Attached is a new version of the atomic operations patch. Lots has
changed since the last post:
Is this at a state where we can performance-test it yet?
--
Josh Berkus
PostgreSQL Experts Inc.
On 2014-06-25 10:39:53 -0700, Josh Berkus wrote:
On 06/25/2014 10:14 AM, Andres Freund wrote:
Hi,
[sorry for the second copy Robert]
Attached is a new version of the atomic operations patch. Lots has
changed since the last post:
Is this at a state where we can performance-test it
On Wed, Jun 25, 2014 at 1:14 PM, Andres Freund and...@2ndquadrant.com wrote:
[sorry for the second copy Robert]
Attached is a new version of the atomic operations patch. Lots has
changed since the last post:
* gcc, msvc work. acc, xlc, sunpro have blindly written support which
should be
Hi,
On 2014-06-25 15:54:37 -0400, Robert Haas wrote:
- The new argument to s_init_lock_sema() isn't used.
It's used when atomics fallback to spinlocks which fall back to
semaphores. c.f. atomics.c.
Since it better be legal to manipulate a atomic variable while holding a
spinlock we cannot
On 06/25/2014 11:36 PM, Andres Freund wrote:
- I completely loathe the file layout you've proposed in
src/include/storage. If we're going to have separate #include files
for each architecture (and I'd rather we didn't go that route, because
it's messy and unlike what we have now), then
Heikki Linnakangas wrote:
On 06/25/2014 11:36 PM, Andres Freund wrote:
- I completely loathe the file layout you've proposed in
src/include/storage. If we're going to have separate #include files
for each architecture (and I'd rather we didn't go that route, because
it's messy and unlike
On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund and...@2ndquadrant.com wrote:
Since it better be legal to manipulate a atomic variable while holding a
spinlock we cannot simply use an arbitrary spinlock as backing for
atomics. That'd possibly cause us to wait on ourselves or cause
deadlocks.
I
On Wed, Jun 25, 2014 at 5:42 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I think having a separate file for each architecture is nice. I totally
agree that they don't belong in src/include/storage, though. s_lock.h has
always been misplaced there, but we've let it be for historical
57 matches
Mail list logo
