Re: Better LWLocks with compare-and-swap (9.4)
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Better LWLocks with compare-and-swap (9.4) |
| Дата | |
| Msg-id | 519A3587.80603@vmware.com обсуждение исходный текст |
| Ответ на | Re: Better LWLocks with compare-and-swap (9.4) (Merlin Moncure <mmoncure@gmail.com>) |
| Ответы |
Re: Better LWLocks with compare-and-swap (9.4)
|
| Список | pgsql-hackers |
On 13.05.2013 17:21, Merlin Moncure wrote: > On Mon, May 13, 2013 at 7:50 AM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> The attached patch is still work-in-progress. There needs to be a configure >> test and fallback to spinlock if a CAS instruction is not available. I used >> the gcc __sync_val_compare_and_swap() builtin directly, that needs to be >> abstracted. Also, in the case that the wait queue needs to be manipulated, >> the code spins on the CAS instruction, but there is no delay mechanism like >> there is on a regular spinlock; that needs to be added in somehow. > > These are really interesting results. Why is the CAS method so much > faster then TAS? If my theory is right, the steep fall is caused by backends being sometimes context switched while holding the spinlock. The CAS method alleviates that, because the lock is never "held" by anyone. With a spinlock, if a process gets context switched while holding the lock, everyone else will have to wait until the process gets context switched back, and releases the spinlock. With the CAS method, if a process gets switched in the CAS-loop, it doesn't hurt others. With the patch, the CAS-loop still spins, just like a spinlock, when the wait queue has to be manipulated. So when that happens, it will behave more or less like the spinlock implementation. I'm not too concerned about that optimizing that further; sleeping and signaling sleeping backends are heavy-weight operations anyway. > Did you see any contention? With the current spinlock implementation? Yeah, per the profile I posted, a lot of CPU time was spent spinning, which is a sign of contention. I didn't see contention with the CAS implemention. Attached is a new version of the patch. I cleaned it up a lot, and added a configure test, and fallback to the good old spinlock implementation if compare-and-swap is not available. Also, if the CAS loops needs to spin, like a spinlock, it now sleeps after a while and updates the "spins_per_delay" like regular spinlock. - Heikki
Вложения
В списке pgsql-hackers по дате отправления: