подробности о просмотре таблицы страниц в многоуровневой подкачке - PullRequest
2 голосов
/ 08 января 2020

Ради простоты я приведу конкретный пример, чтобы объяснить мой вопрос. Обратите внимание, что меня интересуют базовые концепции.

Рассмотрим двухуровневую схему подкачки, то есть у нас есть одна таблица каталогов страниц и несколько таблиц страниц. Чтобы преобразовать виртуальный адрес в физический, мы сначала используем n старших бит нашего виртуального адреса для индексации таблицы каталогов страниц. Оттуда мы получаем адрес таблицы страниц. Используя оставшиеся биты нашего виртуального адреса, мы индексируем эту таблицу страниц, чтобы найти физический адрес наших данных.

Теперь меня интересует следующее: хранит ли таблица каталогов страниц виртуальные или физические адреса? таблицы страниц?

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

Я явно пропустил что-то важное. Мне интересно услышать о концепциях, стоящих за этим, а также о реальных реализациях. Или дайте мне знать, где я могу найти эту информацию.

1 Ответ

3 голосов
/ 08 января 2020

Каталоги страниц в современных иерархических структурах подкачки содержат физические адреса таблиц страниц. Например, https://wiki.osdev.org/Paging показывает формат для 32-битного x86: старшие 20 бит PDE являются физическим адресом с выравниванием по страницам, младшие 12 бит включают флаги для допустимых записей. В основном то же самое, что и записи PTE, указывающие на конечную физическую страницу.

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

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

Запись, которая содержит физический адрес, содержит переводы для раздела ядра виртуального адресного пространства и доступна только в режиме ядра. Записи, которые содержат виртуальные адреса, относятся к процессу и должны меняться при каждом переключении контекста. Это контрастирует с дизайном подкачки x86, где каждый процесс имеет свой собственный каталог страниц, и сопоставления ядра должны быть реплицированы в каждом из них. Тем не менее, только один регистр (CR3) должен меняться при каждом переключении контекста в x86. Кроме того, крошечный «каталог страниц» в VAX делает нагрузку на память таблиц страниц лучше, чем время плоской страницы, но все же не так хорош, как сбалансированная иерархическая таблица страниц, используемая в x86. Другим компромиссом является то, что все виртуальные адреса в 32-битном x86 должны go через два уровня трансляции в памяти для страниц размером 4 КБ, в то время как виртуальные адреса ядра в VAX требуют только одного уровня трансляции в памяти, начиная с первого уровня. проводится в нескольких регистрах. Это неосуществимо для относительно больших каталогов страниц в x86.

Но для того, чтобы использовать многоуровневую подкачку страниц для экономии памяти, нам нужно иметь возможность выкладывать таблицы страниц на диск.

Как правило, создание таблиц страниц с возможностью постраничного отображения не очень важно для уменьшения нагрузки на память структур подкачки. Распределители виртуальной памяти должны (и должны) пытаться распределять память настолько плотно, насколько это возможно, начиная с самых низких доступных уровней таблицы страниц, при этом многие записи в каталоге страниц более высокого уровня вообще не «присутствуют» вместо того, чтобы указывать на целое таблица из 1024 записей (4 кБ), для которых очищен бит Present. Может случиться так, что в течение длительного периода размещения и освобождения таблица страниц становится малонаселенной на самом внутреннем уровне, но плотно заполняется на других уровнях. Именно здесь могут быть полезны страничные таблицы страниц, особенно на платформах, где общий объем доступной или оставшейся физической памяти не достаточен. На Windows таблицы страниц доступны для просмотра на всех уровнях, кроме верхнего. Linux таблицы страниц недоступны для вывода на страницу.

(Или используйте огромные страницы: запись каталога страниц фактически представляет собой перевод 4 МБ виртуальной памяти в непрерывную 4 МБ физической памяти. Так что вы снова избегаете 4 КБ табличного пространства страницы но сопоставьте эту виртуальную память вместо отсутствующей.)


Пейджинг таблиц страниц можно выполнить в x86, используя бит Present в PDE и используя оставшуюся часть в качестве метаданных для различения guish между отображением, которое не должно быть сопоставлено, и разбиением на страницы.

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

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


Группирование выделений в ту же область 4M (или на x86-64, 2M или 1G), что и существующие выделения, позволяет избежать необходимости в новой странице 4k PTE, вместо этого просто заменяя некоторые существующие PTE на Present.

(x86-64 использует 4-уровневые таблицы страниц, с 9 битами на уровень 4 * 9 + 12 = 48-битный виртуальный. Classi c 32-битный x86 использует 2-уровень с 10 битами на уровень: 2 * 10 + 12 = 32-битный виртуальный al.)


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

Отображения ядра, которые одинаковы для всех процессов, могут совместно использовать одни и те же физические страницы для своих таблиц страниц, на что указывает верхняя половина PDE в каждом каталоге страниц. , (У них также будет установлен глобальный бит, чтобы они не аннулировались при смене CR3, так что вам может даже не понадобиться обход страниц для них. Но если обход страниц необходим для устранения пропуска TLB, тогда тот же набор PTE могут оставаться горячими в кэшах данных. Использует ли при просмотре страниц общие таблицы? )

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...