Message-ID: <c892aa85-9e09-42e5-bf74-2302f9693bf4@data-bene.io>
Date: Tue, 8 Jul 2025 02:14:00 +0000
MIME-Version: 1.0
Subject: Re: Adding basic NUMA awareness - Preliminary feedback and outline
 for an extensible approach
From: =?UTF-8?Q?C=C3=A9dric_Villemain?= <cedric.villemain@data-bene.io>
To: Tomas Vondra <tomas@vondra.me>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <099b9433-2855-4f1b-b421-d078a5d82017@vondra.me>
 <1caea3b1-3e0b-4bdb-a630-75671f1f837a@data-bene.io>
 <8b3341ee-1f8e-4dbb-8046-410f71d4a0cb@vondra.me>
 <f1f03ad5-91b4-4028-8304-4e60c3b0a469@data-bene.io>
 <2616b89d-3cd0-4a38-915d-2741da81e0a1@vondra.me>
 <1cd9d7e0-d1ae-4c74-91b5-fbbf8046ee56@data-bene.io>
Autocrypt: addr=cedric.villemain@data-bene.io; keydata=
 xsBNBEvW1WwBCAC6CG3zZnRpQwmSiFoTjaHlgt7RQ2RmYDqSB7DNtOItV9bBDUe4DKxV9iNF
 SoD2yV2LrzsYghWXwI0snHGVGCLkJFYBkqyMnJeli5PoHcn9jI12mOz0hdpsTmTJbH+JCLXF
 admIjh+sz+m7X4net3UQhj8tCaExkdNsw7FWfNr6oHOVkLWlTWh1df1dfTZ3CBZ8vc1L6dIn
 mWe3i2sRGQ/fCy7XfLqjFe5U+D3jXmqF92p7n8v0vwDZarn4MVeBegTtBYUxpM8Bj78Lga9a
 SW+ojYo21Zk/TYn+fdOX4L9nNiRFgnAYVjPlWwjV30WpVlQ56o8U+zV2hCNRQyl5QxkNABEB
 AAHNMUPDqWRyaWMgVmlsbGVtYWluIDxjZWRyaWMudmlsbGVtYWluQGRhdGEtYmVuZS5pbz7C
 wI4EEwEKADgWIQQ66LJpfJwdoY4rdHTbIB9Ms1QXmwUCY3ARzwIbAwULCQgHAgYVCgkICwIE
 FgIDAQIeAQIXgAAKCRDbIB9Ms1QXm9oTB/41lFaXCcwtzLjjN7Qr7lImBjiTOntvhzFOBUMP
 xZWmrXzVl1jVzQm8ubsZNJFB98kw5MrhZjY0sY4x6Txlh6y/OTtpT0RWfZQOGSmfpMq8QDuV
 gymCfXyr0t4XHFou31nlaqEz1CyUi8ZaYdutJAV0L8j1e0LUHvTcCmlHOsb1uS+Xf5yc7ub+
 eRiGtjXwM+OJBYYkFZ2Ebyw7mHWRF4+B3QXUjZhPCQZWBQE1GeX1KxrSCfSKfqujVWCwgiF9
 q5TQisgzVRwPBwsi5Fam2X7UHD8I6ZjaAiKHJXezP/Ied/bup457DlXfOg5ORePJgIldMo0p
 AtHIY1061TckCPs9zsBNBEvW1WwBCAC1iEAHk3lEWEDp9O/DebejwyNr9Zmun6NXPN5axuSj
 5VKWP/2CCmsPkcIQlH70rEtZl4vQjXrdRviRcc56TC/SSXti8uOVr/55uStitTCjKRkpxPdf
 ReOFuOB7OUkHrE3gF6N0UNgOMgmBsT5+rgFm+xqY6TOrvnDVGUbAGkJIdzgTjzeu96BcBEuF
 59r+grsmff8PUGtertKeXBr8NlliYZEFCilqus3PheOetWewysHROQJrqnSkpRP7zJWyFYY5
 W6PWKQlUgcItrWsgPlHl5gmoH68zesTlW1rX1Z56V8vLPF7RTAPG6g1J7l29wLxUYTwF5Y64
 gy+jXAEUJHKZABEBAAHCwF8EGAECAAkFAkvW1WwCGwwACgkQ2yAfTLNUF5ubKAgAtZdh0QJU
 Wc7WfZhoGOcAEADZJ9n6GSuhL+oxuhPfym1zsU70241rKYZH1m53CWWo+aNyThCXJx+HSSRV
 /hLNVW34DErJeNJIYwdxPo5/AjOhIUr4e8gMYuviFESBaMpgl8mSM1B1cHVBMZcsQb43Rc3V
 VfIMNRc4NB16uc7Sm++fbraQq13rB8HC6uYu7PbEAdX3C0IokR3JGb1NghQKga/OoU22KPEx
 Y+bFk4h3vq9MjlKLir0UJZHKSQ5xec6RcehoMBy0FHBEuK/72xN36dR/3bVwyeR76S7xf9UQ
 gXdpciBG95/tLRcpelwx8GaRcivTGc0FCBUzqG/YcCqvcA==
In-Reply-To: <1cd9d7e0-d1ae-4c74-91b5-fbbf8046ee56@data-bene.io>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/c892aa85-9e09-42e5-bf74-2302f9693bf4%40data-bene.io>
Precedence: bulk


>> On 7/7/25 16:51, Cédric Villemain wrote:
>>>>> * Others might use it to integrate PostgreSQL's own resources (e.g.,
>>>>> "areas" of shared buffers) into policies.
>>>>>
>>>>> Hope this perspective is helpful.
>>>>
>>>> Can you explain how you want to manage this by an extension defined at
>>>> the SQL level, when most of this stuff has to be done when setting up
>>>> shared memory, which is waaaay before we have any access to catalogs?
>>>
>>> I should have said module instead, I didn't follow carefully but at some
>>> point there were discussion about shared buffers resized "on-line".
>>> Anyway, it was just to give some few examples, maybe this one is to be
>>> considered later (I'm focused on cgroup/psi, and precisely reassigning
>>> PIDs as needed).
>>>
>>
>> I don't know. I have a hard time imagining what exactly would the
>> policies / profiles do exactly to respond to changes in the system
>> utilization. And why should that interfere with this patch ...
>>
>> The main thing patch series aims to implement is partitioning different
>> pieces of shared memory (buffers, freelists, ...) to better work for
>> NUMA. I don't think there's that many ways to do this, and I doubt it
>> makes sense to make this easily customizable from external modules of
>> any kind. I can imagine providing some API allowing to isolate the
>> instance on selected NUMA nodes, but that's about it.
>>
>> Yes, there's some relation to the online resizing of shared buffers, in
>> which case we need to "refresh" some of the information. But AFAICS it's
>> not very extensive (on top of what already needs to happen after the
>> resize), and it'd happen within the boundaries of the partitioning
>> scheme. There's not that much flexibility.
>>
>> The last bit (pinning backends to a NUMA node) is experimental, and
>> mostly intended for easier evaluation of the earlier parts (e.g. to
>> limit the noise when processes get moved to a CPU from a different NUMA
>> node, and so on).
> 
> The backend pinning can be done by replacing your patch on proc.c to 
> call an external profile manager doing exactly the same thing maybe ?
> 
> Similar to:
> pmroutine = GetPmRoutineForInitProcess();
> if (pmroutine != NULL &&
>      pmroutine->init_process != NULL)
>      pmroutine->init_process(MyProc);
> 
> ...
> 
> pmroutine = GetPmRoutineForInitAuxilliary();
> if (pmroutine != NULL &&
>      pmroutine->init_auxilliary != NULL)
>      pmroutine->init_auxilliary(MyProc);
> 
> Added on some rare places should cover most if not all the requirement 
> around process placement (process_shared_preload_libraries() is called 
> earlier in the process creation I believe).
> 

After a first read I think this works for patches 002 and 005. For this 
last one, InitProcGlobal() may setup things as you do but then expose 
the choice a bit later, basically in places where you added the if 
condition on the GUC: numa_procs_interleave).


-- 
Cédric Villemain +33 6 20 30 22 52
https://www.Data-Bene.io
PostgreSQL Support, Expertise, Training, R&D