Re: Add palloc_aligned() to allow arbitrary power of 2 memory alignment

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add palloc_aligned() to allow arbitrary power of 2 memory alignment
Date: 2022-11-14 02:25:32
Message-ID: CAFBsxsGu85zM4EQktFQkFe0UT4nSQV3+FZ1Xf0NPvF4PNjg+1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 8, 2022 at 8:57 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Tue, 8 Nov 2022 at 05:24, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-11-14 04:04:42 Re: Add test module for Custom WAL Resource Manager feature
Previous Message Thomas Munro 2022-11-14 01:47:14 Re: Suppressing useless wakeups in walreceiver