MIME-Version: 1.0
References: <aFnGQ2lfb8cfukim@msg.df7cb.de>
 <cd16c4a3-2860-46de-a74e-5532d1b2ee39@vondra.me>
 <6342f601-77de-4ee0-8c2a-3deb50ceac5b@vondra.me>
 <aFpg1de9ZfS1QgUt@ip-10-97-1-34.eu-west-3.compute.internal>
 <a3a4fe3d-1a80-4e03-aa8e-150ee15f6c35@vondra.me>
 <aFqHoNXQ/uWKXJ4U@ip-10-97-1-34.eu-west-3.compute.internal>
 <8649a4e3-c60d-4f37-aa6f-e7e7c14c581e@vondra.me>
 <aFqnM/iiL+MB62dG@ip-10-97-1-34.eu-west-3.compute.internal>
 <aFq5HQj016rVS2lm@msg.df7cb.de>
 <8961c087-e49b-4b16-9437-31331625215c@vondra.me>
 <aFrEesaN9YlV0RrJ@msg.df7cb.de>
In-Reply-To: <aFrEesaN9YlV0RrJ@msg.df7cb.de>
From: Jakub Wartak <jakub.wartak@enterprisedb.com>
Date: Wed, 25 Jun 2025 09:15:02 +0200
Message-ID: 
 <CAKZiRmziaa5GtqcSozwvRY_=MPo31nGmgpbm2Jciz=w-BBDsOQ@mail.gmail.com>
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
To: Christoph Berg <myon@debian.org>
Cc: Tomas Vondra <tomas@vondra.me>,
 Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	Andres Freund <andres@anarazel.de>,
 Tomas Vondra <tomas.vondra@postgresql.org>,
	pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAKZiRmziaa5GtqcSozwvRY_%3DMPo31nGmgpbm2Jciz%3Dw-BBDsOQ%40mail.gmail.com>
Precedence: bulk

On Tue, Jun 24, 2025 at 5:30=E2=80=AFPM Christoph Berg <myon@debian.org> wr=
ote:
>
> Re: Tomas Vondra
> > If it's a reliable fix, then I guess we can do it like this. But won't
> > that be a performance penalty on everyone? Or does the system split the
> > array into 16-element chunks anyway, so this makes no difference?
>
> There's still the overhead of the syscall itself. But no idea how
> costly it is to have this 16-step loop in user or kernel space.
>
> We could claim that on 32-bit systems, shared_buffers would be smaller
> anyway, so there the overhead isn't that big. And the step size should
> be larger (if at all) on 64-bit.
>
> > Anyway, maybe we should start by reporting this to the kernel people. D=
o
> > you want me to do that, or shall one of you take care of that? I suppos=
e
> > that'd be better, as you already wrote a fix / know the code better.
>
> Submitted: https://marc.info/?l=3Dlinux-mm&m=3D175077821909222&w=3D2
>

Hi all, I'm quite late to the party (just noticed the thread), but
here's some addition context: it technically didn't make any sense to
me to have NUMA on 32-bit due too small amount of addressable memory
(after all, NUMA is about big iron, probably not even VMs), so in the
first versions of the patchset I've excluded 32-bit (and back then for
some reason I couldn't even find libnuma i386, but Andres pointed to
me that it exists, so we re-added it probably just to stay
consistent). The thread has kind of snowballed since then, but I still
believe that NUMA on 32-bit does not make a lot of sense.

Even assuming future shm interleaving one day in future version,
allocation of small s_b sizes will usually fit a single NUMA node.

-J.