On Thu, Jan 1, 2015 at 09:04:48PM +0100, Andres Freund wrote:
> On January 1, 2015 8:49:06 PM CET, Robert Haas <robertmhaas@gmail.com> wrote:
> >On Thu, Jan 1, 2015 at 11:59 AM, Andres Freund <andres@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +