Re: Draft for basic NUMA observability

Hi,

On 2025-04-05 18:29:22 -0400, Andres Freund wrote:
> I think one thing that the docs should mention is that calling the numa
> functions/views will force the pages to be allocated, even if they're
> currently unused.
>
> Newly started server, with s_b of 32GB an 2MB huge pages:
>
> grep ^Huge /proc/meminfo
> HugePages_Total: 34802
> HugePages_Free: 34448
> HugePages_Rsvd: 16437
> HugePages_Surp: 0
> Hugepagesize: 2048 kB
> Hugetlb: 76517376 kB
>
> run
> SELECT node_id, sum(size) FROM pg_shmem_allocations_numa GROUP BY node_id;
>
> Now the pages that previously were marked as reserved are actually allocated:
>
> grep ^Huge /proc/meminfo
> HugePages_Total: 34802
> HugePages_Free: 18012
> HugePages_Rsvd: 1
> HugePages_Surp: 0
> Hugepagesize: 2048 kB
> Hugetlb: 76517376 kB
>
>
> I don't see how we can avoid that right now, but at the very least we ought to
> document it.

The only allocation where that really matters is shared_buffers. I wonder if
we could special case the logic for that, by only probing if at least one of
the buffers in the range is valid.

Then we could treat a page status of -ENOENT as "page is not mapped" and
display NULL for the node_id?

Of course that would mean that we'd always need to
pg_numa_touch_mem_if_required(), not just the first time round, because we
previously might not have for a page that is now valid. But compared to the
cost of actually allocating pages, the cost for that seems small.

Greetings,

Andres Freund