Как выглядит содержимое таблицы страниц после того, как страница выгружена на диск?
Насколько я понимаю, таблица страниц отображает виртуальные адреса в физические адреса. Но что, если страница была выгружена на диск? Разве расположение данных не заняло бы больше битов для записи, чем физический адрес? Не меняется ли расположение данных при изменении файла подкачки? Эта проблема решается по-разному в разных операционных системах?
1 ответ
Давайте сначала рассмотрим более простой вопрос:
Не меняется ли расположение данных при изменении файла подкачки?
В файле подкачки нет изменений, которые бы приводили к изменению расположения существующих в нем данных. Если файл подкачки расширен, в его конец просто добавляется больше кластеров (сгруппированных по "экстентам" или "прогонам"), поэтому расположение существующих данных не меняется. Расположение файла подкачки всегда относительно начала файла подкачки, поэтому, даже если уже существующие экстенты были каким-то образом перемещены, расположение файла подкачки не изменится.
Теперь о битах:
Разве расположение данных не заняло бы больше битов для записи, чем физический адрес?
Да, если файл подкачки может быть больше возможного объема физической памяти, вам потребуется больше битов, чтобы указать страницу в файле подкачки, чем биты, чтобы указать физический номер страницы.
В x86 без включенного PAE в записи таблицы страниц (PTE) есть 20 бит для номера физической страницы (PFN, сокращение от "номер кадра страницы"). (PTE - 32 бита. Остальные 12 - биты флага, бит 0 - бит "действительный" или "присутствующий на странице", который говорит, что вы не получите ошибку страницы при обращении к странице. Три из битов флага зарезервированы для использование ОС. Другие имеют такие значения, как "только для чтения", "доступен только в режиме ядра", "отключение кэша" и т. д.) (Все в этом параграфе определяется архитектурой ЦП - оно не зависит от ОС.)
В Windows те же самые биты в PTE, которые содержат PFN для допустимой страницы, для страницы, которая находится в файле подкачки, действительно используются для хранения файла location-inside-page-file. Это выражается в смещении в единицах размера страницы от начала файла подкачки. Это ограничивает размер файлов подкачки до 4 ГБ, так же как 20-битный PFN для физических страниц ограничивает объем ОЗУ до 4 ГБ в этих системах.
Тем не менее, вы можете иметь несколько файлов подкачки. В PTE есть еще четыре бита, которые для страницы в файле подкачки указывают номер файла подкачки. Таким образом, может быть 16 файлов подкачки, в общей сложности 64 ГБ возможного пространства подкачки.
Когда вы включаете PAE на более старых процессорах только для x86, PTE становятся шириной 64 бита, и ЦП реализует 24-битную (по сравнению с 20) PFN в PTE. Это позволяет использовать 64 ГБ ОЗУ, а в Windows - 64 ГБ подкачки. В этом формате PTE много неиспользуемых битов, поэтому ОС может фактически поддерживать большие файлы подкачки; Я не уверен, если 32-битная Windows делает.
На более новых 64-битных процессорах в 64-битном режиме имеется 40 бит PFN, и, опять же, те же биты используются для хранения смещения файла подкачки для недопустимых (то есть, отсутствующих) страниц. Итак, ОЗУ или файл подкачки, мы можем описать 2^40 страниц - это один "двоичный триллион" страниц, с 1024 до 4-го. И каждая страница 4 КиБ. Следовательно, максимальный размер файла подкачки 4 ПиБ, а также максимальный объем ОЗУ, поддерживаемый оборудованием. И снова Windows говорит, что вы можете иметь несколько файлов подкачки. Я не думаю, что мы скоро столкнемся с ограничениями пространства подкачки.:)
Все вышеперечисленное, которое не обеспечивается ЦП, зависит от ОС. На самом деле нет никакой причины, по которой файл местоположения внутри страницы должен вообще храниться в PTE; другая структура может быть использована. На таких процессорах, как PowerPC, которые используют хешированную таблицу страниц, ОС не может сохранить ее в PTE, поскольку недопустимый PTE вообще не сохраняется в структуре HPT.
Но на x86/x64 действительно нет причин не использовать недействительный PTE. Между прочим, это работает, потому что, когда "действительный" бит сброшен, MMU не заботится ни на один бит (каламбур) о остальной части PTE. Таким образом, для недействительных PTE все, кроме одного бита, доступны для использования ОС по своему усмотрению. На самом деле в Windows есть несколько других форм "недействительных PTE", в зависимости от состояния страницы. Например, для страницы в резервном или измененном списке поле PFN по-прежнему содержит физическое местоположение страницы в ОЗУ. PTE для недопустимой страницы может ссылаться на "дескриптор виртуального адреса" или, если это общая страница, на "прототип PTE". Аппаратный MMU никогда не видит ни одну из этих структур, только PTE.
Полное описание приведено в главе " Внутренняя структура Windows " Соломона, Руссиновича и Ионеску.