Hi all,
I created a patch for PostgreSQL and x86 architecture.
This patch address a Opteron-specific
behavior regarding some assembler statements.
The patch based on a patch to PostgreSQL 8.0.3 which was worked out by
RedHat.
Tom did change src/include/storage/s_lock.h for PostgreSQL 8.1.x. This
change is only for x86_64. I need to compile PostgreSQL 8.1.4 for 32-bit
on a Opteron. The reason for the 32-bit binary is a failover/test box
with XEONs which didn't know anything about EM64T.
Anyhow, I change the i386 part of s_lock.h too.
BTW: Tom did a great job on BufMgrLock. The original patch for pg 8.0
did push the performance with many parallel queries on another level.
We did run internal benchmarks and the patch version was 2.5 times
faster. The benefit of this change to Pg 8.1.4 is much smaller. I did a
test with pg_bench and the benefit is at around 10 percent.
This change was tested on Opteron, XEON MP w/o EM64T and XEON DP without
any issues.
Cheers
Sven.
diff -Naur postgresql-8.1.4.orig/src/include/storage/s_lock.h postgresql-8.1.4/src/include/storage/s_lock.h
--- postgresql-8.1.4.orig/src/include/storage/s_lock.h 2005-10-11 22:41:32.000000000 +0200
+++ postgresql-8.1.4/src/include/storage/s_lock.h 2006-05-31 09:19:04.000000000 +0200
@@ -125,12 +125,9 @@
* extra test appears to be a small loss on some x86 platforms and a small
* win on others; it's by no means clear that we should keep it.
*/
+ /* xchg implies a LOCK prefix, so no need to say LOCK explicitly */
__asm__ __volatile__(
- " cmpb $0,%1 \n"
- " jne 1f \n"
- " lock \n"
" xchgb %0,%1 \n"
- "1: \n"
: "+q"(_res), "+m"(*lock)
:
: "memory", "cc");
@@ -189,8 +186,8 @@
* is a huge loss. On EM64T, it appears to be a wash or small loss,
* so we needn't bother to try to distinguish the sub-architectures.
*/
+ /* xchg implies a LOCK prefix, so no need to say LOCK explicitly */
__asm__ __volatile__(
- " lock \n"
" xchgb %0,%1 \n"
: "+q"(_res), "+m"(*lock)
:
