Re: Adding basic NUMA awareness

Hello.

cfbot started reporting "needs rebase" this morning, so here is v20261023
rebased onto 14fea8a4c3.

The conflict is worth mentioning because it is a real interaction rather
than context drift. 4b97fd15fb ("Report shared buffer exhaustion as
insufficient resources") replaced

elog(ERROR, "no unpinned buffers available");

in StrategyGetBuffer() with an ereport carrying
ERRCODE_INSUFFICIENT_RESOURCES. 0010 moves that error site: the
per-partition helper returns NULL so the caller can try the other
partitions, and the error is raised in the caller only once every
partition has been scanned. So the two patches touch the same few lines
for different reasons.

I kept the NULL return and carried your new ereport, wording and errcode
unchanged, to the place the error now lives. localbuf.c already says
"could not find an unpinned local buffer" after that commit, and the
shared path now matches it.

0001 shmem_populate and shmem_interleave GUCs (Tomas)
0002 infrastructure for partitioning of shared buffers (Tomas)
0003 NUMA: shared buffers partitioning (Tomas)
0004 clock-sweep: track one second chance per buffer, not a 0..5 count
0005 clock-sweep: admit demand-loaded pages on probation
0006 clock-sweep: bound the work one allocation can do
0007 clock-sweep: let the background writer spend chances when the
sweep starves
0008 clock-sweep: basic partitioning (Tomas)
0009 clock-sweep: balancing of allocations (Tomas)
0010 clock-sweep: scan all partitions (Tomas)
0011 partitioned clocksweep and NUMA goodies (Jakub)
0012 cached CPU/NUMA node and locality-aware balancing (Jakub)
0013 pgindent and typedefs.list

Apart from the ereport in 0010 the only content change since the last
post is 0013, which is new and is formatting only.

The one structural decision in here that is mine rather than inherited is
the ordering.

0004-0007 come before the partitioning work so that
0008-0012 partition the second-chance state rather than a 0..5 counter
that a later patch replaces underneath them.

The reason is measured, partitioning on its own makes the worst case for
a single allocation 4.1-4.6x worse than unpartitioned master on x86 and
2.8-4.2x worse on aarch64, because each partition's hand can starve
independently, and the bound in 0006 is what removes it. Ordered the
other way, 0008 introduces a regression that 0009 through 0012 carry
until the bound arrives.

best.

-greg