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<sfr...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
