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
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.
* W
On Mon, Jul 14, 2014 at 12:47 AM, Andres Freund
wrote:
> On 2014-07-08 11:51:14 +0530, Amit Kapila wrote:
> > On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila
> > wrote:
> > Further review of patch:
> > 1.
> > /*
> > * pg_atomic_test_and_set_flag - TAS()
> > *
> > * Acquire/read barrier semantics
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 severa
Hi Amit,
On 2014-07-08 11:51:14 +0530, Amit Kapila wrote:
> On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila
> wrote:
> > On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund
> wrote:
>
> Further review of patch:
> 1.
> /*
> * pg_atomic_test_and_set_flag - TAS()
> *
> * Acquire/read barrier semantics.
On Sat, Jul 12, 2014 at 1:26 AM, Martijn van Oosterhout
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 barriers are defin
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 th
On Wed, Jul 9, 2014 at 8:58 PM, Robert Haas wrote:
> On Tue, Jul 8, 2014 at 2:21 AM, Amit Kapila
wrote:
> > On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila
> > wrote:
> >
> > Further review of patch:
> > 1.
> > /*
> > * pg_atomic_test_and_set_flag - TAS()
> > *
> > * Acquire/read barrier semanti
On Tue, Jul 8, 2014 at 2:21 AM, Amit Kapila wrote:
> On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila
> wrote:
>> On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund
>> wrote:
>
> Further review of patch:
> 1.
> /*
> * pg_atomic_test_and_set_flag - TAS()
> *
> * Acquire/read barrier semantics.
> */
>
On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila
wrote:
> On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund
wrote:
Further review of patch:
1.
/*
* pg_atomic_test_and_set_flag - TAS()
*
* Acquire/read barrier semantics.
*/
STATIC_IF_INLINE_DECLARE bool
pg_atomic_test_set_flag(volatile pg_atomic_flag
On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund
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 atomic ops usage.
>
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
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)
> mast
On 2014-07-02 09:27:52 +0300, Ants Aasma wrote:
> On Fri, Jun 27, 2014 at 9:00 PM, Andres Freund 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,
On Fri, Jun 27, 2014 at 9:00 PM, Andres Freund 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 (and prototyped) w
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 Mon, Jun 30, 2014 at 2:54 PM, Andres Freund
wrote:
> On 2014-06-30 11:04:53 +0530, Amit Kapila wrote:
> > On Sun, Jun 29, 2014 at 2:54 PM, Andres Freund
wrote:
> > > Yes, intentionally so. It's often important to get/set the current
value
> > > without the cost of emitting a memory barrier. I
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 d
On 2014-06-30 13:45:52 -0400, Tom Lane wrote:
> Robert Haas 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
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 12:54:10 -0400, Tom Lane wrote:
> Robert Haas 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
> > cou
Robert Haas 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 like lwlock.c to h
On 2014-06-30 13:15:23 -0400, Robert Haas wrote:
> On Mon, Jun 30, 2014 at 12:54 PM, Tom Lane 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
On Mon, Jun 30, 2014 at 12:54 PM, Tom Lane 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 bound to the ti
Robert Haas 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 op
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
On Sat, Jun 28, 2014 at 4:25 AM, Andres Freund 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 currently valid
On 2014-06-30 11:04:53 +0530, Amit Kapila wrote:
> On Sun, Jun 29, 2014 at 2:54 PM, Andres Freund wrote:
> > On 2014-06-29 11:53:28 +0530, Amit Kapila wrote:
> > > On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund
> > > I think it is better to have some discussion about it. Apart from this,
> > > to
On Sun, Jun 29, 2014 at 2:54 PM, Andres Freund
wrote:
> On 2014-06-29 11:53:28 +0530, Amit Kapila wrote:
> > On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund
> > I think it is better to have some discussion about it. Apart from this,
> > today I noticed atomic read/write doesn't use any barrier sem
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
> >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 s
On 2014-06-29 11:53:28 +0530, Amit Kapila wrote:
> On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund
> > 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 discuss which semant
On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund
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 = InterlockedCo
On 06/27/2014 08:15 PM, Robert Haas wrote:
On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund 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
On 2014-06-27 22:47:02 -0400, Robert Haas wrote:
> On Fri, Jun 27, 2014 at 2:00 PM, Andres Freund wrote:
> > On 2014-06-27 13:15:25 -0400, Robert Haas wrote:
> >> On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund
> >> wrote:
> >> > I don't really see usecases where it's not related data that's bein
On 2014-06-28 11:58:41 +0530, Amit Kapila wrote:
> On Wed, Jun 25, 2014 at 10:44 PM, Andres Freund
> 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
> >
On Wed, Jun 25, 2014 at 10:44 PM, Andres Freund
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 to implement TAS,
On Fri, Jun 27, 2014 at 2:00 PM, Andres Freund wrote:
> On 2014-06-27 13:15:25 -0400, Robert Haas wrote:
>> On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund
>> 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 us
On 2014-06-27 13:15:25 -0400, Robert Haas wrote:
> On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund 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
On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund 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
> spinlock. So the slowpath
On Thu, Jun 26, 2014 at 1:47 PM, Tom Lane wrote:
> Robert Haas 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 fields while you have the spinlock?
> I
On 2014-06-26 11:47:15 -0700, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund
> > 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.
Robert Haas writes:
> On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund 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, are
>>> loop-until-it-works.
>> W
On Thu, Jun 26, 2014 at 7:21 AM, Andres Freund wrote:
> On 2014-06-25 20:22:31 -0400, Robert Haas wrote:
>> On Wed, Jun 25, 2014 at 5:42 PM, Heikki Linnakangas
>> wrote:
>> > I think having a separate file for each architecture is nice. I totally
>> > agree that they don't belong in src/include/s
On Thu, Jun 26, 2014 at 6:20 AM, 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
>> wrote:
>> > Since it better be legal to manipulate a atomic variable while holding a
>> > spinlock we cannot simply use an arbitrary spinl
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
> > wrote:
> > > Since it better be legal to manipulate a atomic variable while holding a
> > > spinlock we cannot simply use an arb
On 2014-06-26 07:44:14 -0500, Merlin Moncure wrote:
> On Thu, Jun 26, 2014 at 5:20 AM, 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
> >> wrote:
> >> > Since it better be legal to manipulate a atomic variable while h
On Thu, Jun 26, 2014 at 5:20 AM, 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
>> wrote:
>> > Since it better be legal to manipulate a atomic variable while holding a
>> > spinlock we cannot simply use an arbitrary spinl
On 2014-06-25 20:22:31 -0400, Robert Haas wrote:
> On Wed, Jun 25, 2014 at 5:42 PM, Heikki Linnakangas
> 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,
On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
> On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund 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 Wed, Jun 25, 2014 at 5:42 PM, Heikki Linnakangas
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 reasons, but
> now that
On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund 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 think that's going
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
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 sho
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 simp
On Wed, Jun 25, 2014 at 1:14 PM, Andres Freund 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 relatively easy t
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 perfo
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.
http:/
57 matches
Mail list logo
