Feedback-ID: id4a34324:Fastmail
Date: Mon, 23 Jun 2025 11:14:54 -0400
From: Andres Freund <andres@anarazel.de>
To: Christoph Berg <myon@debian.org>
Cc: Tomas Vondra <tomas.vondra@postgresql.org>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
Message-ID: <g3mywoeo7jmh6rci7epx2ishowgz65q2j7ek3c5f3lxcmvuktg@ler2fsv4szmn>
References: <E1u1tr8-003BbN-2E@gemulon.postgresql.org>
 <aEtDozLmtZddARdB@msg.df7cb.de>
 <aFln0lUZke2eEZsP@msg.df7cb.de>
 <aFlpO2lBsMjqarbp@msg.df7cb.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aFlpO2lBsMjqarbp@msg.df7cb.de>
Archived-At: 
 <https://www.postgresql.org/message-id/g3mywoeo7jmh6rci7epx2ishowgz65q2j7ek3c5f3lxcmvuktg%40ler2fsv4szmn>
Precedence: bulk

Hi,

On 2025-06-23 16:48:27 +0200, Christoph Berg wrote:
> Re: To Tomas Vondra
> > 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.

The problem is that the kernel function just gives bogus results for pages
that *are* present in memory but that have only touched in another process
that has mapped the same range of memory.


> One-time touching might also not be enough, what if the pages later
> get swapped out and the monitoring functions are called again?

I don't think that's a problem, the process still has a relevant page table
entry in that case.

Greetings,

Andres Freund