Because userspace rarely actually faults in all the pages it allocates.

Surely the source of the waste here is the userspace program not using the memory it allocated, rather than whether or not the kernel overcommits memory. Attributing this to overcommit behavior is invalid.

▲

PunchyHamster 2 days ago | parent | next [-]

The waste comes with asterisk

That "waste" (that overcommit turns into "not a waste") means you can do far less allocations, with overcommit you can just allocate a bunch of memory and use it gradually, instead of having to do malloc() every time you need a bit of memory and free() every time you get rid of it.

You'd also increase memory fragmentation that way possibly hitting performance.

It's also pretty much required for GCed languages to work sensibly

▲

jcalvinowens 3 days ago | parent | prev | next [-]

Obviously. But all programs do that and have done it forever, it's literally the very reason overcommit exists.

	▲	userbinator 2 days ago \| parent [-]
		Only the poorly-written ones, which are unfortunately the majority of them.

▲

nickelpro 3 days ago | parent | prev [-]

Reading COW memory doesn't cause a fault. It doesn't mean unused literally.

And even if it's not COW, there's nothing wrong or inefficient about opportunistically allocating pages ahead of time to avoid syscall latency. Or mmapping files and deciding halfway through you don't need the whole thing.

There are plenty of reasons overcommit is the default.