Message-ID: <403f66db-6e7f-4522-8cca-0a416c65325e@vondra.me>
Date: Thu, 26 Jun 2025 10:53:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Christoph Berg <myon@debian.org>, Andres Freund <andres@anarazel.de>,
 Tomas Vondra <tomas.vondra@postgresql.org>,
 pgsql-hackers@lists.postgresql.org
References: <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>
 <b54df21b-6595-4031-baf8-7c87851794c8@vondra.me>
 <aFziGyw6z17xocA2@ip-10-97-1-34.eu-west-3.compute.internal>
Content-Language: en-US
From: Tomas Vondra <tomas@vondra.me>
In-Reply-To: <aFziGyw6z17xocA2@ip-10-97-1-34.eu-west-3.compute.internal>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/403f66db-6e7f-4522-8cca-0a416c65325e%40vondra.me>
Precedence: bulk

On 6/26/25 08:00, Bertrand Drouvot wrote:
> Hi,
> 
> On Tue, Jun 24, 2025 at 10:32:25PM +0200, Tomas Vondra wrote:
>> On 6/24/25 17:30, Christoph Berg wrote:
>>> 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. Do
>>>> you want me to do that, or shall one of you take care of that? I suppose
>>>> that'd be better, as you already wrote a fix / know the code better.
>>>
>>> Submitted: https://marc.info/?l=linux-mm&m=175077821909222&w=2
>>>
>>
>> Thanks! Now we wait ...
> 
> It looks like that the bug is "confirmed" and that it will be fixed:
> https://marc.info/?l=linux-kernel&m=175088392116841&w=2
> 

Yay! I like how the first response is "you sent the patch wrong" ;-)


cheers

-- 
Tomas Vondra