В дополнение к другим ответам вы можете настроить Linux так, чтобы она требовала резервного копирования для любой выделенной памяти, даже если программы не используют ее.
Однако чрезмерная загрузка памяти и страх перед убийцей OOM не являются необходимыми частями опыта Linux. Просто установив для параметра sysctl vm/overcommit_memory значение 2, вы отключите поведение overcommit и навсегда остановите работу OOM killer. В большинстве современных систем должно быть достаточно дискового пространства, чтобы обеспечить достаточный файл подкачки для большинства ситуаций. Вместо того, чтобы не допустить уничтожения процессов домашних животных при исчерпании избыточной памяти, может быть проще всего избежать этой ситуации. [ Передышка от убийцы ООМ ]
Если программа выделяет память, ядро может просто пометить больше страниц подкачки как зафиксированные. Это указание хранится в диспетчере памяти ядра, фактическое дисковое пространство еще не затронуто. До тех пор, пока эта память не будет использована, на самом деле ничего не нужно менять местами. Если они никогда не используются, то использование свопа будет колебаться, не влияя на производительность.
Поскольку процессы представлены в своем собственном адресном пространстве или в "представлении" (именно так работает своп), у ядра есть много возможностей для управления этим. Используя пример разветвления также из статьи, ссылки на которую приведены выше, поскольку вероятность того, что страницы с общей памятью имеют гораздо больше шансов, чем свежее выделение большого объема неиспользуемой памяти, может быть выделена память для копирования при записи, что увеличивает количество операций подкачки. Когда он действительно записан (что может не произойти), тогда этот "совершенный обмен" может быть заменен любым неиспользуемым ОЗУ (что увеличивает использование ОЗУ и уменьшает использование свопинга). Представьте себе процесс с выделенным 500 МБ, который разветвляется на машине со всей или почти всей используемой оперативной памятью. Если в разделе подкачки доступно 500 МБ (а дисковое пространство дешевое, то насколько велик 1% современных дисков TB?:P), нет необходимости копировать память (пока, и, возможно, никогда), но ядро может гарантировать "успешно" и продолжайте использовать страницы общей памяти как можно дольше.
Таким образом, можно избежать возможности убийцы OOM, и гораздо проще спроектировать большинство программ с предположением, что выделения памяти (включая "неявные" выделения с помощью чего-то вроде fork) будут либо успешными, либо неудачными немедленно, с практическим пониманием, что если память должна быть поменяйте местами, это может повлиять на производительность. Это воздействие почти всегда незначительно, но в худшем случае приводит к перебросу подкачки (все же иногда предпочтительнее, чем прямой сбой ядра или убийца OOM).
Хотя я не знаю точных деталей того, как работает менеджер памяти Linux, этот ответ - мое собственное обобщенное понимание и то, что я помню, читая за эти годы. Я попытался отредактировать этот ответ так, чтобы потребовалось минимальное понимание дизайна ОС (это значительно сложнее и не то, чем я сам ужасно интересуюсь), но, кажется, немного разболтано; пожалуйста, дайте мне знать, если вы видите, как это можно улучшить. С другой стороны, это не может быть таким смущающим основным вопросом.
