Hi,
On 2022-11-15 16:58:10 -0500, Greg Stark wrote:
> So I think it's kind of cute that you've implemented these as agnostic
> wrappers that work with any allocator ... but why?
>
> I would have expected the functionality to just be added directly to
> the allocator to explicitly request whole aligned pages which IIRC
> it's already capable of doing but just doesn't have any way to
> explicitly request.
We'd need to support it in multiple allocators, and they'd code quite similar
to this because for allocations that go directly to malloc.
It's possible that we'd want to add optional support for aligned allocations
to e.g. aset.c but not other allocators - this patch would allow to add
support for that transparently.
> DirectIO doesn't really need a wide variety of allocation sizes or
> alignments, it's always going to be the physical block size which
> apparently can be as low as 512 bytes but I'm guessing we're always
> going to be using 4kB alignment and multiples of 8kB allocations.
Yep - I posted numbers in some other thread showing that using a larger
alignment is a good idea.
> Wouldn't just having a pool of 8kB pages all aligned on 4kB or 8kB
> alignment be simpler and more efficient than working around misaligned
> pointers and having all these branches and arithmetic happening?
I'm quite certain it'd increase memory usage, rather than reduce it - there's
not actually a whole lot of places that need aligned pages outside of bufmgr,
so the pool would just be unused most of the time. And you'd need special code
to return those pages to the pool when the operation using the aligned buffer
fails - whereas integrating with memory contexts already takes care of
that. Lastly, there's other places where we can benefit from aligned
allocations far smaller than 4kB (most typically cacheline aligned, I'd
guess).
Greetings,
Andres Freund