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
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 |