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:

Reply via email to