On Fri, Mar 25, 2016 at 9:11 AM, Andres Freund <and...@anarazel.de> wrote: > On March 25, 2016 1:04:13 PM GMT+01:00, Robert Haas <robertmh...@gmail.com> > wrote: >>On Fri, Mar 25, 2016 at 3:05 AM, Andres Freund <and...@anarazel.de> >>wrote: >>> On 2015-11-12 19:59:54 +0000, Robert Haas wrote: >>>> Move each SLRU's lwlocks to a separate tranche. >>>> >>>> This makes it significantly easier to identify these lwlocks in >>>> LWLOCK_STATS or Trace_lwlocks output. It's also arguably better >>>> from a modularity standpoint, since lwlock.c no longer needs to >>>> know anything about the LWLock needs of the higher-level SLRU >>>> facility. >>>> >>>> Ildus Kurbangaliev, reviewd by Álvaro Herrera and by me. >>> >>> Before this commit the lwlocks were cacheline aligned, but that's not >>> the case anymore afterwards; afaics. I think that should be fixed? I >>> guess it'd be good to avoid duplicating the code for aligning, so >>maybe >>> we ought to add a ShmemAllocAligned or something? >> >>Does it actually matter? I wouldn't have thought the I/O locks had >>enough traffic for it to make any difference. >> >>But in any case I think the right solution is probably this: >> >>--- a/src/backend/storage/ipc/shmem.c >>+++ b/src/backend/storage/ipc/shmem.c >>@@ -173,7 +173,7 @@ ShmemAlloc(Size size) >> /* >> * ensure all space is adequately aligned. >> */ >>- size = MAXALIGN(size); >>+ size = CACHELINEALIGN(size); >> >> Assert(ShmemSegHdr != NULL); >> >>It's stupid that we keep spending time and energy figuring out which >>shared memory data structures require alignment and which ones don't. >>Let's just align them *all* and be done with it. The memory cost >>shouldn't be more than a few kB. > > Last time I proposed that it got shut down. I agree it'd be a good idea, it's > really hard to find alignment issues.
Gosh, I thought *I* had last proposed that and *you* had shot it down. Why ever would we not want to do that? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
