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

From Andres Freund
Subject Re: Add palloc_aligned() to allow arbitrary power of 2 memory alignment
Date
Msg-id 20221115191902.leitlzgxbif6abon@awork3.anarazel.de
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
Hi,

On 2022-11-15 23:36:53 +1300, David Rowley wrote:
> On Tue, 15 Nov 2022 at 11:11, Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Moving forward with TDE
Next
From: Andres Freund
Date:
Subject: Re: Add sub-transaction overflow status in pg_stat_activity