Когда виртуальное адресное пространство больше, чем физическая память, ОС может использовать подкачку для удаления кадров страницы (например, вытеснение LRU)
Предположим, что виртуальный адрес является 48-разрядным(поэтому размер одного виртуального адресного пространства составляет 256 ТиБ), и вы запускаете 123 процесса, каждый из которых имеет свое собственное виртуальное адресное пространство.Это в сумме составляет 31488 ТБ виртуального адресного пространства. Примечание: это "очень нормально" для современного ПК 80x86, работающего под управлением современной ОС (Windows, Linux, ...).
Из этого 31488 TiB:
почти все из них будут неиспользованы и помечены как "не присутствующие".Если программное обеспечение пытается получить к нему доступ, вы получаете ошибку страницы, обработчик ошибок страницы понимает, что это ошибка, и вы, вероятно, в конечном итоге получаете SIGSEGV (или «синий экран смерти» или ...).Поскольку она не используется, ОС не требуется ОЗУ или дисковое пространство для нее.
некоторые из них будут одинаковыми, загруженными в ОЗУ один раз, а затем отображенными вмного виртуальных адресных пространств.Это чрезвычайно распространено как для самого ядра, так и для общих библиотек / DLL.Сюда также входят случаи, когда одно и то же ОЗУ используется для кэша виртуальной файловой системы и для файлов, отображаемых в память, или одно и то же ОЗУ отображается в 2 или более процессов как «общая память», или когда одно и то же ОЗУ отображается в 2 или болеевиртуальные адресные пространства как «копирование при записи» (например, после fork()).
некоторые будут «выделяться при записи» - буквально та же страница, полная нулей, отображенных вмного виртуальных адресов во многих виртуальных адресных пространствах, где, если вы пишете в него, вы получаете ошибку страницы, а обработчик ошибок страницы выделяет новую страницу ОЗУ для страницы, на которую вы пытались записать.Это позволяет ОС делать вид, что огромное количество виртуального пространства выделено и заполнено нулями без использования ОЗУ или дискового пространства (до тех пор, пока оно фактически не будет изменено).
некоторые будут(измененные) данные, которые являются уникальными для конкретного процесса.
Конечный результат заключается в том, что 31488 ТиБ общего виртуального пространства может потребовать всего несколько ГиБ ОЗУ (и, вероятно, не будетиспользовать пространство подкачки вообще).
Чрезмерная фиксация
ОС делает кучу трюков, чтобы притвориться, что память была выделена, хотя на самом деле ее не было.Это создает потенциал для наихудшего случая, когда вся память, которую претендует ОС, фактически должна быть выделена.Есть два способа справиться с этим:
a) Отказаться от предоставления процессам возможности выделять больше, если вы не можете охватить наихудший случай (например, возвращать ошибку «недостаточно памяти», когда процесс пытается выделить больше, чемОС может поставить).Это плохо, потому что наихудший случай крайне маловероятен, и вы в конечном итоге приводите к сбоям программного обеспечения без причины («недостаточно памяти», когда на самом деле достаточно памяти для покрытия текущих требований).
b) Разрешить процессам выделять больше(в пределах разумного), даже если вы не можете охватить худший случай.В большинстве случаев это работает нормально, но если на самом деле случается худший случай, что-то должно сломаться (например, ОС завершает процесс, чтобы освободить часть оперативной памяти).
Лучший вариант (на мой взгляд) - первыйопция (не разрешать чрезмерную фиксацию), но иметь большой объем пространства подкачки.По существу;это похоже на «разрешить чрезмерную фиксацию оперативной памяти, но не разрешать избыточную фиксацию пространства подкачки + оперативная память»;где ОС, вероятно, будет работать медленно (из-за чрезмерного использования пространства подкачки), прежде чем она начнет говорить процессам «больше нет памяти»;и где большую часть времени все будет в ОЗУ (и в идеале пространство подкачки используется только для покрытия маловероятного наихудшего случая).