Re: s_lock() seems too aggressive for machines with many sockets

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: s_lock() seems too aggressive for machines with many sockets
Дата
Msg-id 3740.1433946332@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: s_lock() seems too aggressive for machines with many sockets  (Andres Freund <andres@anarazel.de>)
Ответы Re: s_lock() seems too aggressive for machines with many sockets
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Unfortunately there's no portable futex support. That's what stopped us
> from adopting them so far.  And even futexes can be significantly more
> heavyweight under moderate contention than our spinlocks - It's rather
> easy to reproduce scenarios where futexes cause significant slowdown in
> comparison to spinning in userspace (just reproduce contention on a
> spinlock where the protected area will be *very* short - i.e. no cache
> misses, no branches or such).

Which, you'll note, is the ONLY case that's allowed by our coding rules
for spinlock use.  If there are any locking sections that are not very
short straight-line code, or at least code with easily predicted branches,
we need to fix those before we worry about the spinlock mechanism per se.
Optimizing for misuse of the mechanism is not the way.
        regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: s_lock() seems too aggressive for machines with many sockets
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: reaper should restart archiver even on standby