Как выглядит содержимое таблицы страниц после того, как страница выгружена на диск?

501
Deckel

Насколько я понимаю, таблица страниц отображает виртуальные адреса на физические адреса. Но что, если страница была выгружена на диск? Разве расположение данных не заняло бы больше битов для записи, чем физический адрес? Не меняется ли расположение данных при изменении файла подкачки? Эта проблема решается по-разному в разных операционных системах?

1

1 ответ на вопрос

1
Jamie Hanrahan

Давайте сначала рассмотрим более простой вопрос:

Не меняется ли расположение данных при изменении файла подкачки?

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

Теперь о битах:

Разве расположение данных не заняло бы больше битов для записи, чем физический адрес?

Да, если файл подкачки может быть больше возможного объема физической памяти, вам потребуется больше битов, чтобы указать страницу в файле подкачки, чем биты, чтобы указать физический номер страницы.

В x86 без PAE имеется 20 бит в записи таблицы страниц (PTE) для физического номера страницы (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 PiB, а также максимальный объем ОЗУ, поддерживаемый аппаратным обеспечением. И снова Windows говорит, что вы можете иметь несколько файлов подкачки. Я не думаю, что мы скоро столкнемся с ограничениями пространства подкачки. :)

Все вышеперечисленное, которое не обеспечивается ЦП, зависит от ОС. На самом деле нет никакой причины, по которой файл местоположения внутри страницы вообще должен храниться в PTE; другая структура может быть использована. На таких процессорах, как PowerPC, которые используют хешированную таблицу страниц, ОС не может сохранить ее в PTE, поскольку недопустимый PTE вообще не сохраняется в структуре HPT.

Но на x86 / x64 действительно нет причин не использовать недействительный PTE. Между прочим, это работает, потому что, когда «действительный» бит очищен, MMU не заботится ни об одном бите (каламбур) относительно остальной части PTE. Таким образом, для недопустимых PTE все, кроме одного бита, доступны для использования ОС по своему усмотрению. На самом деле в Windows есть несколько других форм «недействительных PTE», в зависимости от состояния страницы. Например, для страницы в резервном или измененном списке поле PFN по-прежнему содержит физическое местоположение страницы в ОЗУ. PTE для недопустимой страницы может ссылаться на «дескриптор виртуального адреса» или, если это общая страница, на «прототип PTE». Аппаратный MMU никогда не видит ни одну из этих структур, только PTE.

Полное описание приведено в главе « Внутренняя структура Windows » Соломона, Руссиновича и Ионеску.

Спасибо за хороший отзыв! Если у вас есть какие-либо последующие вопросы, не стесняйтесь публиковать их в качестве комментариев или изменять исходный вопрос. Jamie Hanrahan 8 лет назад 0

Похожие вопросы