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


Reply via email to