On Thu, Jan 1, 2015 at 05:59:25PM +0100, Andres Freund wrote: > > That seems like a strange approach. I think it's pretty sensible to > > try to ensure that allocated blocks of shared memory have decent > > alignment, and we don't have enough of them for aligning on 64-byte > > boundaries (or even 128-byte boundaries, perhaps) to eat up any > > meaningful amount of memory. The BUFFERALIGN() stuff, like much else > > about the way we manage shared memory, has also made its way into the > > dynamic-shared-memory code. So if we do adjust the alignment that we > > guarantee for the main shared memory segment, we should perhaps adjust > > DSM to match. But I guess I don't understand why you'd want to do it > > that way. > > The problem is that just aligning the main allocation to some boundary > doesn't mean the hot part of the allocation is properly aligned. shmem.c > in fact can't really do much about that - so fully moving the > responsibility seems more likely to ensure that future code thinks about > alignment.
Yes, there is shared memory allocation alignment and object alignment. Since there are only about 50 cases of these, a worst-case change to force 64-byte alignment would only cost 3.2k of shared memory. It might make sense to make them all 64-byte aligned to reduce CPU cache contention, but we have to have actual performance numbers to prove that. My two patches allow individual object alignment to be tested. I have not been able to see any performance difference (<1%) with: $ pgbench --initialize --scale 100 pgbench $ pgbench --protocol prepared --client 32 --jobs 16 --time=100 --select-only pgbench on my dual-socket 16 vcore server. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers