Re: copy.c allocation constant

On Wed, Jan 24, 2018 at 06:25:01PM +0100, Tomas Vondra wrote:
> >
>
> I think there there are two things to consider - aset.c and glibc.
>
> In AllocSet this is handled as over-sized chunk, that is chunk greater
> than ALLOC_CHUNK_LIMIT (which ends up being 8kB). Which means it's
> allocated as a separate block, and does not go through the freelists. So
> the size does not follow the usual "power of 2" pattern and is only
> maxalign-ed, and then freed immediately on pfree.
>
> So for AllocSet we're fine, and this should not result in any memory
> inefficiency, assuming there are not many such requests (which would
> result in many malloc/free calls, which may be somewhat expensive).
>
> At the glibc level ... I'm not so sure. AFAIK glibc uses an allocator
> with similar ideas (freelists, ...) so hopefully it's fine too.
>
> And then there are the systems without glibc, or with other libc
> implementations. No idea about those.

Thanks for the analysis.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +