Обсуждение: pgsql: Move each SLRU's lwlocks to a separate tranche.
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. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/fe702a7b3f9f2bc5bf6d173166d7d55226af82c8 Modified Files -------------- src/backend/access/transam/clog.c | 2 +- src/backend/access/transam/commit_ts.c | 2 +- src/backend/access/transam/multixact.c | 4 ++-- src/backend/access/transam/slru.c | 37 +++++++++++++++++++++----------- src/backend/access/transam/subtrans.c | 2 +- src/backend/commands/async.c | 2 +- src/backend/storage/lmgr/lwlock.c | 23 -------------------- src/backend/storage/lmgr/predicate.c | 2 +- src/include/access/slru.h | 10 ++++++++- 9 files changed, 41 insertions(+), 43 deletions(-)
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? Greetings, Andres Freund
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
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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.