Where do overcommit and COW come in?
Conversation
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
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
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
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.
1
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).
1
1
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.
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.
1
1
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.
1