Re: pgsql: Introduce pg_shmem_allocations_numa view
От | Tomas Vondra |
---|---|
Тема | Re: pgsql: Introduce pg_shmem_allocations_numa view |
Дата | |
Msg-id | 403f66db-6e7f-4522-8cca-0a416c65325e@vondra.me обсуждение исходный текст |
Ответ на | Re: pgsql: Introduce pg_shmem_allocations_numa view (Tomas Vondra <tomas@vondra.me>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: