Re: Adding basic NUMA awareness
От | Ashutosh Bapat |
---|---|
Тема | Re: Adding basic NUMA awareness |
Дата | |
Msg-id | CAExHW5te2bTcYHLu2zLPjfwQU3gWhE9T7w++BFhTbUiqAVaY4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Adding basic NUMA awareness (Tomas Vondra <tomas@vondra.me>) |
Ответы |
Re: Adding basic NUMA awareness
Re: Adding basic NUMA awareness |
Список | pgsql-hackers |
On Wed, Jul 2, 2025 at 12:37 AM Tomas Vondra <tomas@vondra.me> wrote: > > > 3) v1-0003-freelist-Don-t-track-tail-of-a-freelist.patch > > Minor optimization. Andres noticed we're tracking the tail of buffer > freelist, without using it. So the patch removes that. > The patches for resizing buffers use the lastFreeBuffer to add new buffers to the end of free list when expanding it. But we could as well add it at the beginning of the free list. This patch seems almost independent of the rest of the patches. Do you need it in the rest of the patches? I understand that those patches don't need to worry about maintaining lastFreeBuffer after this patch. Is there any other effect? If we are going to do this, let's do it earlier so that buffer resizing patches can be adjusted. > > There's also the question how this is related to other patches affecting > shared memory - I think the most relevant one is the "shared buffers > online resize" by Ashutosh, simply because it touches the shared memory. I have added Dmitry to this thread since he has written most of the shared memory handling code. > > I don't think the splitting would actually make some things simpler, or > maybe more flexible - in particular, it'd allow us to enable huge pages > only for some regions (like shared buffers), and keep the small pages > e.g. for PGPROC. So that'd be good. The resizing patches split the shared buffer related structures into separate memory segments. I think that itself will help enabling huge pages for some regions. Would that help in your case? > > But there'd also need to be some logic to "rework" how shared buffers > get mapped to NUMA nodes after resizing. It'd be silly to start with > memory on 4 nodes (25% each), resize shared buffers to 50% and end up > with memory only on 2 of the nodes (because the other 2 nodes were > originally assigned the upper half of shared buffers). > > I don't have a clear idea how this would be done, but I guess it'd > require a bit of code invoked sometime after the resize. It'd already > need to rebuild the freelists in some way, I guess. Yes, there's code to build the free list. I think we will need code to remap the buffers and buffer descriptor. -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: