On Wed, 21 Feb 2024 at 00:02, Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
>
> On Tue, 20 Feb 2024 at 11:02, David Rowley <dgrowleyml@gmail.com> wrote:
> > On Fri, 26 Jan 2024 at 01:29, Matthias van de Meent
> > <boekewurm+postgres@gmail.com> wrote:
> > > >> + allocSize = MAXALIGN(sizeof(BumpContext)) + Bump_BLOCKHDRSZ +
> > > >> + if (minContextSize != 0)
> > > >> + allocSize = Max(allocSize, minContextSize);
> > > >> + else
> > > >> + allocSize = Max(allocSize, initBlockSize);
> > >
> > > Shouldn't this be the following, considering the meaning of "initBlockSize"?
> >
> > No, we want to make the blocksize exactly initBlockSize if we can. Not
> > initBlockSize plus all the header stuff. We do it that way for all
> > the other contexts and I agree that it's a good idea as it keeps the
> > malloc request sizes powers of 2.
>
> One part of the reason of my comment was that initBlockSize was
> ignored in favour of minContextSize if that was configured, regardless
> of the value of initBlockSize. Is it deliberately ignored when
> minContextSize is set?
Ok, it's a good question. It's to allow finer-grained control over the
initial block as it allows it to be a fixed given size without
affecting the number that we double for the subsequent blocks.
e.g BumpContextCreate(64*1024, 8*1024, 1024*1024);
would make the first block 64K and the next block 16K, followed by
32K, 64K ... 1MB.
Whereas, BumpContextCreate(0, 8*1024, 1024*1024) will start at 8K, 16K ... 1MB.
It seems useful as you might have a good idea of how much memory the
common case has and want to do that without having to allocate
subsequent blocks, but if slightly more memory is required sometimes,
you probably don't want the next malloc to be double the common size,
especially if the common size is large.
Apart from slab.c, this is how all the other contexts work. It seems
best to keep this and not to go against the grain on this as there's
more to consider if we opt to change the context types of existing
contexts.
David