Date: Mon, 23 Jun 2025 16:42:26 +0200
From: Christoph Berg <myon@debian.org>
To: Tomas Vondra <tomas.vondra@postgresql.org>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
Message-ID: <aFln0lUZke2eEZsP@msg.df7cb.de>
References: <E1u1tr8-003BbN-2E@gemulon.postgresql.org>
 <aEtDozLmtZddARdB@msg.df7cb.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="p321qshW2LpuyTKe"
Content-Disposition: inline
In-Reply-To: <aEtDozLmtZddARdB@msg.df7cb.de>
Archived-At: 
 <https://www.postgresql.org/message-id/aFln0lUZke2eEZsP%40msg.df7cb.de>
Precedence: bulk


--p321qshW2LpuyTKe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Re: To Tomas Vondra
> This is acting up on Debian's 32-bit architectures, namely i386, armel
> and armhf:

... and x32 (x86_64 instruction set with 32-bit pointers).

>  SELECT COUNT(*) >= 0 AS ok FROM pg_shmem_allocations_numa;
> +ERROR:  invalid NUMA node id outside of allowed range [0, 0]: -14
> 
> -14 seems to be -EFAULT, and move_pages(2) says:
>        -EFAULT
>               This is a zero page or the memory area is not mapped by the process.

I did some debugging on i386 and made it print the page numbers:

 SELECT COUNT(*) >= 0 AS ok FROM pg_shmem_allocations_numa;
+WARNING:  invalid NUMA node id outside of allowed range [0, 0]: -14 for page 35
+WARNING:  invalid NUMA node id outside of allowed range [0, 0]: -14 for page 36
...
+WARNING:  invalid NUMA node id outside of allowed range [0, 0]: -14 for page 32768
+WARNING:  invalid NUMA node id outside of allowed range [0, 0]: -14 for page 32769

So it works for the first few pages and then the rest is EFAULT.

I think the pg_numa_touch_mem_if_required() hack might not be enough
to force the pages to be allocated. Changing that to a memcpy() didn't
help. Is there some optimization that zero pages aren't allocated
until being written to?

Why do we try to force the pages to be allocated at all? This is just
a monitoring function, it should not change the actual system state.
Why not just skip any page where the status is <0 ?

The attached patch removes that logic. Regression tests pass, but we
probably have to think about whether to report these negative numbers
as-is or perhaps convert them to NULL.

Christoph

--p321qshW2LpuyTKe
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="0001-Don-t-force-allocate-pages-for-pg_get_shmem_allocati.patch"