Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

On Fri, Mar 25, 2016 at 9:11 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On March 25, 2016 1:04:13 PM GMT+01:00, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>On Fri, Mar 25, 2016 at 3:05 AM, Andres Freund <andres(at)anarazel(dot)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