Re: LWLock contention: I think I understand the problem

> No. We'll still wake up the same processes as now: either one would-be
> exclusive lock holder, or multiple would-be shared lock holders.
> But what I'm proposing is that they don't get granted the lock at that
> instant; they have to try to get the lock once they actually start to
> run.
>
> Once in a while, they'll fail to get the lock, either because the
> original releaser reacquired the lock, and then ran out of his time
> quantum before releasing it, or because some third process came along
> and acquired the lock. In either of these scenarios they'd have to
> block again, and we'd have wasted a process dispatch cycle. The
> important thing though is that the current arrangement wastes a process
> dispatch cycle for every acquisition of a contended-for lock.
>
> What I had not really focused on before, but it's now glaringly obvious,
> is that on modern machines one process time quantum (0.01 sec typically)
> is enough time for a LOT of computation, in particular an awful lot of
> trips through the buffer manager or other modules with shared state.
> We want to be sure that a process can repeatedly acquire and release
> the shared lock for as long as its time quantum holds out, even if there
> are other processes waiting for the lock. Otherwise we'll be swapping
> processes too often.

OK, I understand what you are saying now. You are not talking about the
SysV semaphore but a level above that.

What you are saying is that when we release a lock, we are currently
automatically giving it to another process that is asleep and may not be
scheduled to run for some time. We then continue processing, and when
we need that lock again, we can't get it because the sleeper is holding
it. We go to sleep and the sleeper wakes up, gets the lock, and
continues.

What you want to do is to wake up the sleeper but not give them the lock
until they are actually running and can aquire it themselves.

Seems like a no-brainer win to me. Giving the lock to a process that is
not currently running seems quite bad to me. It would be one thing if
we were trying to do some real-time processing, but throughput is the
key for us.

If you code up a patch, I will test it on my SMP machine using pgbench.
Hopefully this will help Tatsuo's 4-way AIX machine too, and Linux.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026