Re: Changing types of block and chunk sizes in memory contexts

Hi,

On 2023-06-29 11:58:27 +0200, Tomas Vondra wrote:
> On 6/29/23 01:34, Andres Freund wrote:
> > On 2023-06-28 23:26:00 +0200, Tomas Vondra wrote:
> >> Yeah. FWIW I was interested what the patch does in practice, so I
> >> checked what pahole says about impact on struct sizes:
> >>
> >> AllocSetContext 224B -> 208B (4 cachelines)
> >> GenerationContext 152B -> 136B (3 cachelines)
> >> SlabContext 200B -> 200B (no change, adds 4B hole)
> ...
> > That would save another 12 bytes, if I calculate correctly. 25% shrinkage
> > together ain't bad.
> >
>
> I don't oppose these changes, but I still don't quite believe it'll make
> a measurable difference (even if we manage to save a cacheline or two).
> I'd definitely like to see some measurements demonstrating it's worth
> the extra complexity.

I hacked (emphasis on that) a version together that shrinks AllocSetContext
down to 176 bytes.

There seem to be some minor performance gains, and some not too shabby memory
savings.

E.g. a backend after running readonly pgbench goes from (results repeat
precisely across runs):

pgbench: Grand total: 1361528 bytes in 289 blocks; 367480 free (206 chunks); 994048 used
to:
pgbench: Grand total: 1339000 bytes in 278 blocks; 352352 free (188 chunks); 986648 used

Running a total over all connections in the main regression tests gives less
of a win (best of three):

backends grand blocks free chunks used
690 1046956664 111373 370680728 291436 676275936

to:

backends grand blocks free chunks used
690 1045226056 111099 372972120 297969 672253936

the latter is produced with this beauty:
ninja && m test --suite setup --no-rebuild && m test --no-rebuild --print-errorlogs regress/regress -v && grep "Grand total" testrun/regress/regress/log/postmaster.log|sed -E -e 's/.*Grand total: (.*) bytes in (.*) blocks; (.*) free \((.*) chunks\); (.*) used/\1\t\2\t\3\t\4\t\5/'|awk '{backends += 1; grand += $1; blocks += $2; free += $3; chunks += $4; used += $5} END{print backends, grand, blocks, free, chunks, used}'

There's more to get. The overhead of AllocSetBlock also plays into this. Both
due to the keeper block and obviously separate blocks getting allocated
subsequently. We e.g. don't need AllocBlockData->next,prev as 8 byte pointers
(some trickiness would be required for external blocks, but they could combine
both).

Greetings,

Andres Freund