On 2013-10-13 20:39:21 +0200, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > The question about platforms that simply cannot provide such atomics
> > like PA-RISC, which afaics is the only one, remains tho. I am not sure
> > we really want to provide codepaths that are only going to be tested
> > there.
>
> PA-RISC is a dead architecture. According to wikipedia, HP hasn't sold
> any such machines since 2008, and won't support them beyond 2013. If
> that really is the only case we're worried about supporting, it's an
> easy decision.
Great.
> What worries me more is that you mentioned several cases where the gcc
> atomics exist but need kernel support. I have to think that a trap
> to the kernel would make the operation so expensive as to be a serious
> performance loss, not gain. So it seems to me that platforms like that
> are essentially being kicked to the curb if we make this change, even
> if they theoretically could still work.
I think it's not that bad on most - they all seem to use some more
lightweight trap mechanisms that basically just change protection and
stops interrupts while doing the math. No chance of scheduling and such.
> Are there any that we really care about?
I don't think so. At least not if we're restricting ourselves to 32bit
cmpxchg/xadd which I think will be enough for the first rounds of
improvement.
It's:
- PA-RISC
- sparc before ultrasparcs (1995)
- Multi-CPU/core SuperH before SH4 (uni SH2 has some cute interrupt handling tricks, that do not require a trap)
- arm before v6
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services