The FAQ's tone of dismissive superiority with respect to overcommit is very offputting. The author suggests that only people who don't know how virtual memory w

The FAQ's tone of dismissive superiority with respect to overcommit is very offputting. The author suggests that only people who don't know how virtual memory works can oppose overcommit; it's curious then how the author reveals some virtual memory knowledge gaps. Specifically, the difference between address space reservation (which does not require backing storage) and commit charge (which does) seems lost on him. Yes, you need backing storage to handle the possibility that a process might actually make copies of all COW pages (that's what we mean by "commit charge" --- the number of pages the kernel has voluntarily promised to deliver at some point. The right way to reduce the pressure on commit that these mappings cause is to not have so many of them in the first place. There's no reason PIC shared libraries need to be PROT_WRITE; there's no reason big programs like web browsers need to use fork(2) instead of the VM-efficient vfork(2). (Small programs can use fork and its COW commit charge without causing real problems, even on non-sloppy (err, "strict overcommit") systems. Linux's default overcommit policy is terrible in part because it discourages people from learning about the difference between reserving address space and actually reserving memory, and the "FAQ" just confuses the issue more.