Linux Memory Overcommit (2007)

Re:Linux Memory Overcommit (2007) by cyberax on Monday August 19, 2024 @12:21PM (#41292353)

> If you have overcommit disabled, it will be user-space processes making syscalls mmap() or sbrk() to get more heap memory (in which small allocations reside), that fails with an error return code, I assume.

Nope. No overcommit simply means that the OOM killer will be invoked earlier. The errors likely won't happen on the synchronous path due to the way glibc() maps the pages.

Long ago, I tried to write an OOM-resilient container library, and I wanted to test it. It worked as expected on Windows, but on Linux I was not able to get NULLs from malloc(). No amount of MLOCKALL and other tricks helped.

[ Parent | on HN ]

Re:Linux Memory Overcommit (2007) by ploxiln on Monday August 19, 2024 @02:54PM (#41293659)

Wow, that's disappointing. It seems there's really a lot of reasons to just accept overcommit on linux. (Browers, js engines used in various components now, databases that fork, many existing libraries not expecting allocations to fail ... and I guess they really don't after all?!)

[ Parent | on HN ]

Re:Linux Memory Overcommit (2007) by wmf on Monday August 19, 2024 @07:53PM (#41295523)

I think to fix this stuff you'd have to time travel back to 1980 or so. There's just so much software dependent on the broken behavior and a culture of not fixing things.

[ Parent | on HN ]