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

On 2016-04-10 16:08:56 -0700, Andres Freund wrote:
> On 2016-04-05 15:48:22 -0400, Robert Haas wrote:
> > On Fri, Mar 25, 2016 at 12:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > >> On Fri, Mar 25, 2016 at 9:48 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > >>>> 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.
> > >
> > >>> I think such a proposal should come with a measurement, not just
> > >>> speculation about what it costs.
> > >
> > >> About 6kB with default settings. See below.
> > >
> > > Sold, then.
> >
> > Excellent. Done.
>
> InitBufferPool() manually fixes up alignment; that should probably be
> removed now.
>
> 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));

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

and

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

- Andres