On 2013-10-13 20:39:21 +0200, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
