On Thu, Jan 1, 2015 at 09:04:48PM +0100, Andres Freund wrote: > On January 1, 2015 8:49:06 PM CET, Robert Haas <robertmh...@gmail.com> wrote: > >On Thu, Jan 1, 2015 at 11:59 AM, Andres Freund <and...@2ndquadrant.com> > >wrote: > >> 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. > > > >That's true, but if you don't align the beginnings of the allocations, > >then it's a lot more complicated for the code to properly align stuff > >within the allocation. It's got to insert a variable amount of > >padding based on the alignment it happens to get. > > Hm? Allocate +PG_CACHELINE_SIZE and do var = CACHELINEALIGN(var).
Yeah, I am afraid we have to do that anyway --- you can see it in my patch too. I guess if you had the shmem allocation aligned on 64-byte boundries and required all allocations to be a multiple of 64, that would work too. -- 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
