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

From Robert Haas
Subject Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.
Date
Msg-id CA+TgmoZ4PsKukByQbpADpshmhWY99C-fM_Pk5RE2_ahXTn8BNA@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.  (Andres Freund <andres@anarazel.de>)
Responses Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.
Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.
List pgsql-hackers
On Fri, Mar 25, 2016 at 3:05 AM, Andres Freund <andres@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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Rahila Syed
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Next
From: Robert Haas
Date:
Subject: Re: VS 2015 support in src/tools/msvc