On Mon, Jan 29, 2024 at 8:48 PM John Naylor <johncnaylorls@gmail.com> wrote:
>
> On Mon, Jan 29, 2024 at 2:29 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> > > > +/*
> > > > + * Calculate the slab blocksize so that we can allocate at least 32 chunks
> > > > + * from the block.
> > > > + */
> > > > +#define RT_SLAB_BLOCK_SIZE(size) \
> > > > + Max((SLAB_DEFAULT_BLOCK_SIZE / (size)) * (size), (size) * 32)
> > > >
> > > > The first parameter seems to be trying to make the block size exact,
> > > > but that's not right, because of the chunk header, and maybe
> > > > alignment. If the default block size is big enough to waste only a
> > > > tiny amount of space, let's just use that as-is.
>
> > If we use SLAB_DEFAULT_BLOCK_SIZE (8kB) for each node class, we waste
> > [snip]
> > We might want to calculate a better slab block size for node256 at least.
>
> I meant the macro could probably be
>
> Max(SLAB_DEFAULT_BLOCK_SIZE, (size) * N)
>
> (Right now N=32). I also realize I didn't answer your question earlier
> about block sizes being powers of two. I was talking about PG in
> general -- I was thinking all block sizes were powers of two. If
> that's true, I'm not sure if it's because programmers find the macro
> calculations easy to reason about, or if there was an implementation
> reason for it (e.g. libc behavior). 32*2088 bytes is about 65kB, or
> just above a power of two, so if we did round that up it would be
> 128kB.
Thank you for your explanation. It might be better to follow other
codes. Does the calculation below make sense to you?
RT_SIZE_CLASS_ELEM size_class = RT_SIZE_CLASS_INFO[i];
Size inner_blocksize = SLAB_DEFAULT_BLOCK_SIZE;
while (inner_blocksize < 32 * size_class.allocsize)
inner_blocksize <<= 1;
As for the lock mode in dsa.c, I've posted a question[1].
Regards,
[1] https://www.postgresql.org/message-id/CAD21AoALgrU2sGWzgq%2B6G9X0ynqyVOjMR5_k4HgsGRWae1j%3DwQ%40mail.gmail.com
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com