Re: Is the unfair lwlock behavior intended?

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Is the unfair lwlock behavior intended?
Дата
Msg-id CAM3SWZQLnF+QhxJ6tA=1z7iRURPGfwyyVyKkV+W2NO8NetP-qA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Is the unfair lwlock behavior intended?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, May 24, 2016 at 3:50 PM, Andres Freund <andres@anarazel.de> wrote:
>> Jim Gray's paper on the "Convoy phenomenon" remains relevant, decades later:
>>
>> http://www.msr-waypoint.com/en-us/um/people/gray/papers/Convoy%20Phenomenon%20RJ%202516.pdf
>>
>> I could believe that there's a case to be made for per-LWLock fairness
>> characteristics, which may be roughly what Andres meant.
>
> The problem is that half-way fair locks, which are frequently acquired
> both in shared and exclusive mode, have really bad throughput
> characteristics on modern multi-socket systems. We mostly get away with
> fair locking on object level (after considerable work re fast-path
> locking), because nearly all access are non-conflicting.  But
> prohibiting any snapshot acquisitions when there's a single LW_EXCLUSIVE
> ProcArrayLock waiter, can reduce throughput dramatically.

That's a useful example of where things are different for different,
well known cases.

> I don't think randomly processing the wait queue - which is what the
> quoted paper essentially describes - is really useful here. We
> intentionally *ignore* the wait queue entirely if a lock is not
> conflicting, and that's what can prohibit exclusive locks from ever
> succeeding, because you essentially can get repetitions of:

My point about the paper is that it made me reconsider my assumption
that fairness, according to some definition, was essential for
something like LWLocks. The paper made me aware that it's perfectly
acceptable practice to make informed trade-offs around fairness for
what it calls "latches" (what we'd call LWLocks). Maybe that was
obvious to you, but it wasn't to me.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Parallel safety tagging of extension functions
Следующее
От: Noah Misch
Дата:
Сообщение: Re: new tests post-feature freeze (was pgsql: Add TAP tests for pg_dump)