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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.
Date: 2016-03-25 14:11:38
Message-ID: 618335ED-9690-4C95-8915-B79C00C90AA4@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On March 25, 2016 2:48:00 PM GMT+01:00, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>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?

See Tom's response. The reason I didn't do it last time is that we previously had that argument. I think that's just a waste of or time. It's ridiculously hard figuring it alignment issues, I spent days on the buffer desc thing.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2016-03-25 15:19:01 Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.
Previous Message Tom Lane 2016-03-25 13:48:43 Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-03-25 14:15:32 Re: Small patch: Change calling convention for ShmemInitHash (and fix possible bug)
Previous Message Michael Paquier 2016-03-25 13:48:49 Re: Proposal: "Causal reads" mode for load balancing reads without stale data