Re: Add palloc_aligned() to allow arbitrary power of 2 memory alignment - Mailing list pgsql-hackers

From John Naylor
Subject Re: Add palloc_aligned() to allow arbitrary power of 2 memory alignment
Date
Msg-id CAFBsxsGu85zM4EQktFQkFe0UT4nSQV3+FZ1Xf0NPvF4PNjg+1Q@mail.gmail.com
Whole thread Raw
In response to Re: Add palloc_aligned() to allow arbitrary power of 2 memory alignment  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Add palloc_aligned() to allow arbitrary power of 2 memory alignment
List pgsql-hackers

On Tue, Nov 8, 2022 at 8:57 AM David Rowley <dgrowleyml@gmail.com> wrote:

> On Tue, 8 Nov 2022 at 05:24, Andres Freund <andres@anarazel.de> wrote:
> > I doubtthere's ever a need to realloc such a pointer? Perhaps we could just
> > elog(ERROR)?
>
> Are you maybe locked into just thinking about your current planned use
> case that we want to allocate BLCKSZ bytes in each case? It does not
> seem impossible to me that someone will want something more than an
> 8-byte alignment and also might want to enlarge the allocation at some
> point. I thought it might be more dangerous not to implement repalloc.
> It might not be clear to someone using palloc_aligned() that there's
> no code path that can call repalloc on the returned pointer.

I can imagine a use case for arrays of cacheline-sized objects.

> TYPEALIGN() will not work correctly unless the alignment is a power of
> 2. We could modify it to, but that would require doing some modular
> maths instead of bitmasking. That seems pretty horrible when the macro
> is given a value that's not constant at compile time as we'd end up
> with a (slow) divide in the code path.  I think the restriction is a
> good idea. I imagine there will never be any need to align to anything
> that's not a power of 2.

+1

> > Should we handle the case where we get a suitably aligned pointer from
> > MemoryContextAllocExtended() differently?
>
> Maybe it would be worth the extra check. I'm trying to imagine future
> use cases.  Maybe if someone wanted to ensure that we're aligned to
> CPU cache line boundaries then the chances of the pointer already
> being aligned to 64 bytes is decent enough.  The problem is it that
> it's too late to save any memory, it just saves a bit of boxing and
> unboxing of the redirect headers.

To my mind the main point of detecting this case is to save memory, so if that's not possible/convenient, special-casing doesn't seem worth it. 

- Assert((char *) chunk > (char *) block);
+ Assert((char *) chunk >= (char *) block);

Is this related or independent?

--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Suppressing useless wakeups in walreceiver
Next
From: Bharath Rupireddy
Date:
Subject: Re: Add test module for Custom WAL Resource Manager feature