Lock contention (was Re: [PATCHES] update i386 spinlock for hyperthreading)

Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
> Mark ran a DBT-2 testrun with the attached statistics patch applied: It
> collects stats about all lightweight locks and dumps them during
> shutdown. The hottest locks are

> Lock Acquire %contention sleep calls
> 8(WALInsertLock) 8679205 0.030410 263934
> 5(SInvalLock) 68396470 0.001298 88812
> 1(LockMgrLock) 64089418 0.079783 5113215
> 0(BufMgrLock) 246307425 0.120293 29629089

Okay, that more or less squares with my gut feelings about the system.
Good to have some proof.

> I remember there were patches that tried other algorithms instead of the
> simple LRU for the buffer manager. Has anyone tried to change the
> locking of the buffer manager?

LRU etc have nothing to do with this. The majority of trips into the
buffer manager are for ReadBuffer/ReleaseBuffer. What we need is to
figure a way for those operations to use finer-grain locks so they don't
contend so much. However, given that they need to access and possibly
modify global structures (the buffer lookup hashtable and free list),
it's not obvious how to do it. If we could think of a way to divide
those structures into separately lockable portions, we might get somewhere.

> The effect of padding the lightweight locks to a full cacheline appears
> to be negligable:

Good, that squares with what the Linux kernel people seem to think.

regards, tom lane