Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1uTiy4-008vDt-QW
	for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Jun 2025 15:20:20 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1uTiy2-004ALk-Pi
	for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Jun 2025 15:20:19 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <cb@df7cb.de>)
	id 1uTiy2-004ALb-GD
	for pgsql-hackers@lists.postgresql.org; Mon, 23 Jun 2025 15:20:19 +0000
Received: from mout-p-103.mailbox.org ([80.241.56.161])
	by magus.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.96)
	(envelope-from <cb@df7cb.de>)
	id 1uTiy0-003f0O-24
	for pgsql-hackers@lists.postgresql.org;
	Mon, 23 Jun 2025 15:20:18 +0000
Received: from smtp2.mailbox.org (smtp2.mailbox.org
 [IPv6:2001:67c:2050:b231:465::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest
 SHA256)
	(No client certificate requested)
	by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4bQsG60TBVz9srN;
	Mon, 23 Jun 2025 17:20:14 +0200 (CEST)
Date: Mon, 23 Jun 2025 17:20:12 +0200
From: Christoph Berg <myon@debian.org>
To: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tomas.vondra@postgresql.org>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
Message-ID: <aFlwrNqKjHC1vj8h@msg.df7cb.de>
References: <E1u1tr8-003BbN-2E@gemulon.postgresql.org>
 <aEtDozLmtZddARdB@msg.df7cb.de>
 <aFln0lUZke2eEZsP@msg.df7cb.de>
 <aFlpO2lBsMjqarbp@msg.df7cb.de>
 <g3mywoeo7jmh6rci7epx2ishowgz65q2j7ek3c5f3lxcmvuktg@ler2fsv4szmn>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <g3mywoeo7jmh6rci7epx2ishowgz65q2j7ek3c5f3lxcmvuktg@ler2fsv4szmn>
X-Rspamd-Queue-Id: 4bQsG60TBVz9srN
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/aFlwrNqKjHC1vj8h%40msg.df7cb.de>
Precedence: bulk

Re: Andres Freund
> > > 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.

Ok, so we leave the touching in, but still defend against negative
status values?

Christoph