Josh Berkus wrote:
> Initial debug logging of a test on one Xeon system demonstrating this issue
>showed a very large number of unattributed semop() calls. We are still
>following up on this.
>
Postgres has it's own user space spinlock and semaphore implementation.
Both fall back to semop if there is contention.
Hmm. You wrote that the problem is Xeon specific, and that AthlonMP are
unaffected. Perhaps Xeon cpus do not like the s_lock implementation? It
doesn't follow Intel's recommentations:
- no pause instructions.
- always TAS. The recommended approach is nonatomic tests until the
value is 0, then an atomic TAS.
Attached is a gross hack that adds pause instructions. If this doesn't
magically fix your problem, then we must figure out what causes the
semop calls, and avoid them.
Could you ask your Linux hackers why they blame the shared memory
implementation in postgres? I don't see any link between shared memory
and lock contention.
--
Manfred
Index: backend/storage/lmgr/s_lock.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/backend/storage/lmgr/s_lock.c,v
retrieving revision 1.16
diff -c -r1.16 s_lock.c
*** backend/storage/lmgr/s_lock.c 8 Aug 2003 21:42:00 -0000 1.16
--- backend/storage/lmgr/s_lock.c 19 Dec 2003 20:01:33 -0000
***************
*** 111,116 ****
--- 111,117 ----
spins = 0;
}
+ __asm__ __volatile__("rep;nop\n": : : "memory");
}
}