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

From: Andres Freund <andres(at)anarazel(dot)de>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: 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-15 19:19:02
Message-ID: 20221115191902.leitlzgxbif6abon@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-11-15 23:36:53 +1300, David Rowley wrote:
> On Tue, 15 Nov 2022 at 11:11, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Couldn't we reduce the amount of over-allocation by a small amount by special
> > casing the already-aligned case? That's not going to be relevant for page size
> > aligne allocations, but for smaller alignment values it could matter.
>
> I don't quite follow this. How can we know the allocation is already
> aligned without performing the allocation? To perform the allocation
> we must tell palloc what size to allocate. So, we've already wasted
> the space by the time we can tell if the allocation is aligned to what
> we need.

What I mean is that we perhaps could over-allocate by a bit less than
alignto + sizeof(MemoryChunk)
If the value returned by the underlying memory context is already aligned to
the correct value, we can just return it as-is.

We already rely on memory context returning MAXIMUM_ALIGNOF aligned
allocations. Adding the special case, I think, means that the we could safely
over-allocate by "only"
alignto + sizeof(MemoryChunk) - MAXIMUM_ALIGNOF

Which would be a reasonable win for small allocations with a small >
MAXIMUM_ALIGNOF alignment. But I don't think that'll be a very common case?

> Aside from that, there's already a special case for alignto <=
> MAXIMUM_ALIGNOF. But we know no palloc will ever return anything
> aligned less than that in all cases, which is why that can work.

Yep.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-11-15 19:29:54 Re: Add sub-transaction overflow status in pg_stat_activity
Previous Message Jacob Champion 2022-11-15 19:07:54 Re: Moving forward with TDE