On Mon, May 20, 2013 at 11:16:41PM +0300, Heikki Linnakangas wrote:
> On 20.05.2013 23:01, Bruce Momjian wrote:
> >On Thu, May 16, 2013 at 12:08:40PM -0400, Tom Lane wrote:
> >>Stephen Frost<sfrost@snowman.net> writes:
> >>>Isn't this the same issue which has prompted multiple people to propose
> >>>(sometimes with code, as I recall) to rip out our internal spinlock
> >>>system and replace it with kernel-backed calls which do it better,
> >>>specifically by dealing with issues like the above? Have you seen those
> >>>threads in the past? Any thoughts about moving in that direction?
> >>
> >>All of the proposals of that sort that I've seen had a flavor of
> >>"my OS is the only one that matters". While I don't object to
> >>platform-dependent implementations of spinlocks as such, they're not
> >>much of a cure for a generic performance issue.
> >
> >Uh, is this an x86-64-only optimization? Seems so.
>
> All modern architectures have an atomic compare-and-swap instruction
> (or something more powerful that can be used to implement it). That
> includes x86, x86-64, ARM, PowerPC, among others.
>
> There are some differences in how wide values can be swapped with
> it; 386 only supported 32-bit, until Pentium, which added a 64-bit
> variant. I used the 64-bit variant in the patch, but for lwlocks, we
> could actually get away with the 32-bit variant if we packed the
> booleans and the shared lock counter more tightly.
So we are going to need to add this kind of assembly language
optimization for every CPU type?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +