Re: dynamic shared memory and locks

On Mon, Jan 6, 2014 at 11:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think we can eliminate the first of those.  Semaphores for spinlocks
> were a performance disaster fifteen years ago, and the situation has
> surely only gotten worse since then.  I do, however, believe that
> --disable-spinlocks has some use while porting to a new platform.
> (And I don't believe the argument advanced elsewhere in this thread
> that everybody uses gcc; much less that gcc's atomic intrinsics are
> of uniformly high quality even on oddball architectures.)
>
> Heikki's idea has some attraction for porting work whether or not
> you believe that DSM needs to work during initial porting.  By
> default, PG will try to create upwards of ten thousand spinlocks
> just for buffer headers.  It's likely that that will fail unless
> you whack around the kernel's SysV parameters.  Being able to
> constrain the number of semaphores to something sane would probably
> be useful.
>
> Having said all that, I'm not personally going to take the time to
> implement it, and I don't think the DSM patch should be required to
> either.  Somebody who actually needs it can go make it work.

Well, I took a look at this and it turns out not to be very hard, so
here's a patch.  Currently, we allocate 3 semaphore per shared buffer
and a bunch of others, but the 3 per shared buffer dominates, so you
end up with ~49k spinlocks for the default of 128MB shared_buffers.  I
chose to peg the number of semaphores at 1024, which is quite small
compared to the current allocation, but the number of spinlock
allocations that can be in progress at any given time is limited by
the number of running backends.  Even allowing for the birthday
paradox, that should be enough to run at least a few dozen backends
without suffering serious problems due to the multiplexing -
especially because in real workloads, contention is usually
concentrated around a small number of spinlocks that are unlikely to
all be mapped to the same underlying semaphore.

I'm happy enough with this way forward.  Objections?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company