On Tue, Feb 10, 2026 at 6:32 AM Ashutosh Bapat <[email protected]> wrote: [..] > > > To resize a shared memory segment in this layout it's possible to use > > > ftruncate on the memory mapped file. > > > > > > This approach also do not impact the actual memory usage as reported by > > > the kernel. > > > > I still don't see what the point of having multiple mappings and using memfd > > is. We need to reserve the address space for the maximum sized allocation in > > postmaster, otherwise there's absolutely no guarantee that it's available at > > those addresses in all the children - which you do as you explain > > here. Therefore, the maximum size of each "suballocation" needs to be > > reserved > > ahead of time. At which point I don't see the point of having multiple > > mmaps. It just makes things more complicated and expensive (each mmap makes > > fork & exit slower). > > > > Even if we decide to use memfd, because we consider MADV_DONTNEED to not be > > suitable for some reason, what's the point of having more than one mapping > > using memfd? > > There are just two mappings now compared to 6 earlier. If I am reading > Jakub's benchmarking correctly, even 6 segments didn't show much > regression in his benchmarks. Having just two should not see much > regression. If we use multiple mappings we could control the > properties of each segment separately - e.g. use huge pages for some > (buffer blocks) and not for others.
FWIW, Tomas ended up technically using multiple mmap segments too due to NUMA and there appears to be no other way (2*NUMA nodes, for at least Buffer Blocks and PGPROC as I remember, or maybe it was even 3*nodes??). I hope we attack that problem again one day and we can measure the impact again there if needed. -J.
