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 Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
