Логическое адресное пространство больше, чем физическое и резервное хранилище вместе взятые

Что происходит, когда виртуальный адрес настолько велик, что ни в основной памяти, ни на диске недостаточно места для его хранения?

Система виртуальной памяти поддерживает образ логического адресного пространства во вторичном хранилище. Хорошо спроектированная операционная система не позволит процессу отображать логический адрес, который еще не имеет резервной копии во вторичном хранилище. Когда ваше приложение вызывает системную службу для сопоставления страниц с логическим адресным пространством, вызов завершится ошибкой, если для страниц нет доступного вторичного хранилища.

Что происходит, когда страничного фрейма тоже нет на диске?

Есть некоторые плохо разработанные операционные системы, которые будут отображать страницы без дополнительного хранилища. Вы вызываете системную службу для сопоставления страниц, это удается, даже если страницы не могут быть сохранены во вторичном хранилище. В этом случае вы получаете исключение памяти при доступе (и не получаете в своем приложении намека на то, что реальная проблема связана с ошибкой выделения памяти).

Вызвана ли другая ошибка страницы?

No.

В системе логической памяти (поддерживаемой большинством процессоров) страница имеет два состояния:

1. Mapped
2. Unmapped

В системе виртуальной памяти существует три состояния:

1. Mapped
2. Unmapped and valid
3. Unmapped and invalid

Когда происходит ошибка страницы, процессор просто знает, что страница не отображена в память. Затем операционная система должна выяснить, находится ли страница где-то во вторичном хранилище. Если это не так, операция заставляет процесс увидеть исключение. Если это так, операционная система загружает и отображает страницу, позволяя процессу продолжать свою работу.

Когда виртуальное адресное пространство больше, чем физическая память, ОС может использовать подкачку для вытеснения страничных фреймов (например, вытеснение LRU).

Предположим, что виртуальный адрес 48-битный (поэтому размер одного виртуального адресного пространства составляет 256 ТиБ), и вы запускаете 123 процесса, каждый из которых имеет собственное виртуальное адресное пространство. В сумме это составляет 31488 ТиБ виртуального адресного пространства. Примечание. Это "нормально" для современного ПК 80x86 под управлением современной ОС (Windows, Linux, ...).

Из этого 31488 ТиБ:

• почти все это будет неиспользовано и помечено как «отсутствующее». Если программное обеспечение попытается получить к нему доступ, вы получите ошибку страницы, обработчик ошибки страницы поймет, что это ошибка, и вы, вероятно, получите SIGSEGV (или «синий экран смерти» или ...). Поскольку он не используется, ОС не нуждается ни в оперативной памяти, ни в дисковом пространстве.

• некоторые из них будут одинаковыми, загруженными в оперативную память один раз, а затем отображенными во множество виртуальных адресных пространств. Это чрезвычайно распространено для самого ядра и общих библиотек/DLL. Это также включает случаи, когда одна и та же оперативная память используется для кеша виртуальной файловой системы и для отображаемых в память файлов, или одна и та же оперативная память отображается на 2 или более процессов как «общая память», или когда одна и та же оперативная память отображается на 2 или более процессов. виртуальные адресные пространства как «копирование при записи» (например, после fork()).

• некоторые будут «распределяться при записи» — буквально одна и та же страница, полная нулей, отображается на множество виртуальных адресов во многих виртуальных адресных пространствах, где, если вы записываете на нее, вы получаете ошибку страницы, и обработчик ошибки страницы выделяет новую страницу ОЗУ для страница, на которую вы пытались написать. Это позволяет ОС делать вид, что огромное количество виртуального пространства выделено и заполнено нулями, не используя ни ОЗУ, ни место на диске (до тех пор, пока оно не будет изменено).

• некоторые будут (модифицированными) данными, уникальными для конкретного процесса.

Конечным результатом является то, что для 31488 ТиБ общего виртуального пространства может потребоваться всего несколько ГиБ ОЗУ (и, вероятно, вообще не будет использоваться пространство подкачки).

Перебор

ОС делает кучу трюков, чтобы притвориться, что память была выделена, хотя на самом деле это не так. Это создает потенциал для наихудшего случая, когда вся память, которую ОС делает вид, что выделена, на самом деле должна быть выделена. Есть 2 способа справиться с этим:

а) Откажитесь позволить процессам выделять больше, если вы не можете покрыть наихудший случай (например, вернуть ошибку «недостаточно памяти», когда процесс пытается выделить больше, чем может предоставить ОС). Это плохо, потому что наихудший случай крайне маловероятен, и вы в конечном итоге получите сбой программного обеспечения без причины («недостаточно памяти», когда на самом деле памяти достаточно для покрытия текущих требований).

б) Разрешить процессам выделять больше (в пределах разумного), даже если вы не можете покрыть наихудший случай. В большинстве случаев это работает нормально, но если на самом деле происходит худший случай, что-то должно сломаться (например, ОС завершает процесс, чтобы освободить часть оперативной памяти).

Наилучший вариант (на мой взгляд) — это первый вариант (не допускать чрезмерной фиксации), но иметь большой объем подкачки. По сути; это похоже на «разрешить избыточное выделение ОЗУ, но не разрешить избыточное выделение пространства подкачки + ОЗУ»; где ОС, вероятно, будет работать медленно (из-за чрезмерного использования пространства подкачки), прежде чем она начнет сообщать процессам «нет больше памяти»; и где большую часть времени все будет в ОЗУ (и в идеале пространство подкачки используется только для покрытия маловероятного худшего случая).