Conversation

This Tweet was deleted by the Tweet author. Learn more

I understand CoW and overcommit! But then you brought in guard pages as a benefit of overcommit, and my searches on guard pages don't yield anything that requires CoW.

This Tweet was deleted by the Tweet author. Learn more

Paul Crowley

@ciphergoth

Apr 17, 2021

If we didn't have fork, we would very rarely encounter the situation "I need to CoW this vast amount of memory though I'll probably modify very little of it", and so we wouldn't need overcommit.

This Tweet was deleted by the Tweet author. Learn more

Paul Crowley

@ciphergoth

Apr 17, 2021

Yep I'm not against sharing memory, or even CoW. It's specifically overcommit that I hate, and it's only necessary because fork is such an awful bodge.

Replying to

and

In the memory accounting mode, the Linux kernel does not count fresh PROT_NONE mappings. Only memory that can be used and cannot be freely paged out is counted against you (i.e. writable/written anonymous mappings, not memory mapped files).

Replying to

and

Copy-on-write also still works fine without overcommit enabled. The only difference is that fork, etc. will fail if there isn't enough memory available to account for all possibly used memory from the mappings.

Replying to

and

Can also still reserve huge amounts of address space without overcommit as long as you map it as PROT_NONE or PROT_READ initially. Works fine. If you don't directly control how it gets used, you could set up userfaultfd to catch faults and make it PROT_WRITE|PROT_READ as needed.

12:12 PM · Apr 17, 2021Twitter Web App

Replying to

and

Overcommit also has nothing to do with the kernel using a special zero page to deal with reads from fresh mappings. That happens either way. Disabling overcommit just turns on full memory accounting. Doesn't change anything beyond having a limit + tracking usage globally.