Re: s_lock() seems too aggressive for machines with many sockets - Mailing list pgsql-hackers

From Tom Lane
Subject Re: s_lock() seems too aggressive for machines with many sockets
Date
Msg-id 3740.1433946332@sss.pgh.pa.us
Whole thread Raw
In response to Re: s_lock() seems too aggressive for machines with many sockets  (Andres Freund <andres@anarazel.de>)
Responses Re: s_lock() seems too aggressive for machines with many sockets  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: s_lock() seems too aggressive for machines with many sockets
Next
From: Fujii Masao
Date:
Subject: Re: reaper should restart archiver even on standby