On Fri, Aug 30, 2024 at 12:41:37PM GMT, Lorenzo Stoakes wrote: > On Fri, Aug 30, 2024 at 11:56:36AM GMT, Petr Spacek wrote: > > From: Petr Spacek <pspacek@xxxxxxx> > > > > Raise default sysctl vm.max_map_count to INT_MAX, which effectively > > disables the limit for all sane purposes. The sysctl is kept around in > > case there is some use-case for this limit. > > > > The old default value of vm.max_map_count=65530 provided compatibility > > with ELF format predating year 2000 and with binutils predating 2010. At > > the same time the old default caused issues with applications deployed > > in 2024. > > > > State since 2012: Linux 3.2.0 correctly generates coredump from a > > process with 100 000 mmapped files. GDB 7.4.1, binutils 2.22 work with > > this coredump fine and can actually read data from the mmaped addresses. > > > > Signed-off-by: Petr Spacek <pspacek@xxxxxxx> > > NACK. Sorry this may have come off as more hostile than intended... we are welcoming of patches, promise :) It is only because we want to be _super_ careful about things like this that can have potentially problematic impact if you have a buggy program that allocates too many VMAs. It is a NACK, but it's a NACK because of the limit being so high. With steam I believe it is a product of how it performs allocations, and unfortunately this causes it to allocate quite a bit more than you would expect. With jemalloc() that seems strange, perhaps buggy behaviour? It may be reasonable to adjust the default limit higher, and I'm not opposed to that, but it might be tricky to find a level that is sensible across all arches including ones with significantly smaller memory availability. This is what makes choosing this value tricky, thanks for you analysis as to the original choice which does seem less applicable now, but choosing something sensible here might be tricky. Also there may be _somebody_ out there relying on this limit being quite so low. [snip]
