> My understanding is that there was a time when there was no overcommit at all. > If that's the case, understanding why overcommit was introduced would be > helpful.
Linux always had overcommit. The origin of overcommit is virtual memory for the most part. In a classic swapping system without VM the meaning of brk() and thus malloc() is that it allocates memory (or swap). Likewise this is true of fork() and stack extension. In a virtual memory system these allocate _address space_. It does not become populated except by page faulting, copy on write and the like. It turns out that for most use cases on a virtual memory system we get huge amounts of page sharing or untouched space. Historically Linux did guess based overcommit and I added no overcommit support way back when, along with 'anything is allowed' support for certain HPC use cases. The beancounter patches combined with this made the entire setup completely robust but the beancounters never hit upstream although years later they became part of the basis of the cgroups. You can sort of set a current Linux up for definitely no overcommit using cgroups and no overcommit settings. It works for most stuff although last I checked most graphics drivers were terminally broken (and not just to no overcommit but to the point you can remote DoS Linux boxes with a suitably constructed web page and chrome browser) Alan
