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+TgmoZxpmV6LapSSpGLd5ftQ6KAsyqPfxEi_i6jE=OSPfy1Zw@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.  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Apr 11, 2016 at 12:01 AM, Andres Freund <andres@anarazel.de> wrote:
>> InitBufferPool() manually fixes up alignment; that should probably be
>> removed now.

Attached patch does that.

>> I also wonder if it doesn't make sense to fix PG_CACHE_LINE_SIZE to
>> 64byte on x86. I personally think a manual ifdef in pg_config_manual.h
>> is ok for that.
>
> Also, this doesn't seem to be complete. This now aligns sizes to
> cacheline boundaries, but it doesn't actually align the returned values
> afaics? That might kind of work sometimes, if freeoffset is initially
> aligned to PG_CACHE_LINE_SIZE, but that's not guaranteed, it's just
>         shmhdr->freeoffset += MAXALIGN(sizeof(slock_t));

And tries to fix that.

> Additionally, doesn't this obsolete
>
> /*
>  * Preferred alignment for disk I/O buffers.  On some CPUs, copies between
>  * user space and kernel space are significantly faster if the user buffer
>  * is aligned on a larger-than-MAXALIGN boundary.  Ideally this should be
>  * a platform-dependent value, but for now we just hard-wire it.
>  */
> #define ALIGNOF_BUFFER  32

I didn't go as far as trying to remove this; a few other random things
are using it.

> and
>
>         /* extra alignment for large requests, since they are probably buffers */
>         if (size >= BLCKSZ)
>                 newStart = BUFFERALIGN(newStart);

But I got this one.

I fixed the InitBufferPool issue you mentioned in the other email, too.

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

Attachment

pgsql-hackers by date:

Previous
From: Stas Kelvich
Date:
Subject: Re: Speedup twophase transactions
Next
From: nummervet nummervet
Date:
Subject: Re[4]: [HACKERS] Execute ignoring cursor?