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