Re: Atomics hardware support table & supported architectures - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Atomics hardware support table & supported architectures
Date
Msg-id 20140618212143.GY3115@awork2.anarazel.de
Whole thread Raw
In response to Re: Atomics hardware support table & supported architectures  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2014-06-18 17:04:49 -0400, Robert Haas wrote:
> On Wed, Jun 18, 2014 at 12:13 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > There might be cases where that's true, but in the majority of cases
> > where the variable isn't highly contended it's just about the same. In
> > many cases the microcode will implement atomic ops using ll/sc
> > operations internally anyway.
> 
> But if the variable isn't highly contended, then why are we messing
> around with atomic ops in the first place?

a) Quite often the "strange" atomic op is only needed to allow a more  performance critical codepart to use atomic ops
(e.g.setting flags  atomically is only required to make atomic pins work).
 
b) A spinlock protected region is often more likely to take longer than  a single atomic op because it'll often touch
morecachelines and  such. For such cmpxchg loops there's pretty much no intermediary  instructions inbetween which the
cachelinecould be stolen by another  core.
 
c) The overall amount of bus traffic is often noticeably lower with a  atomic op because the average total number of
lockedinstructions is  lower (unlocking often enough requires another atomic op or barrier)
 


> > Why don't you pass it to configure or add it in Makefile.custom? That's
> > what I do.
> 
> Yeah, I should probably do that instead.  But I still think the point
> that two different commiters have managed to flip that flag by
> accident is telling.

Not arguing against having the configure flag here (already decided),
just wondering whether your life could be made easier :)

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Atomics hardware support table & supported architectures
Next
From: Kevin Grittner
Date:
Subject: Re: delta relations in AFTER triggers