Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.
От | Andres Freund |
---|---|
Тема | Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche. |
Дата | |
Msg-id | 618335ED-9690-4C95-8915-B79C00C90AA4@anarazel.de обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche. (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On March 25, 2016 2:48:00 PM GMT+01:00, Robert Haas <robertmhaas@gmail.com> wrote: >On Fri, Mar 25, 2016 at 9:11 AM, Andres Freund <andres@anarazel.de> >wrote: >> On March 25, 2016 1:04:13 PM GMT+01:00, Robert Haas ><robertmhaas@gmail.com> wrote: >>>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. >> >> 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 awaste 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.
В списке pgsql-hackers по дате отправления: