Re: Atomics hardware support table & supported architectures

On 2014-06-18 17:04:49 -0400, Robert Haas wrote:
> On Wed, Jun 18, 2014 at 12:13 PM, Andres Freund <andres(at)2ndquadrant(dot)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 more cachelines and
such. For such cmpxchg loops there's pretty much no intermediary
instructions inbetween which the cacheline could 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 locked instructions 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