В чем преимущество многоступенчатой ​​подкачки x86 по сравнению с одностраничной таблицей?

В качестве конкретного примера рассмотрим 32-битную схему подкачки x86. В руководстве разработчика Intel я нашел следующий рисунок, на котором показано, как 32-битный пейджинг может преобразовать линейный адрес в физический адрес.

Диаграмма пейджинга

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

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


person Jacob Garby    schedule 01.05.2020    source источник
comment
Без этапов вам понадобилась бы одна гигантская таблица страниц с миллионом записей, даже если у вас всего несколько сотен действительных страниц. Для такой большой таблицы страниц потребуется 4 МБ памяти, что является проблемой, если на вашем компьютере изначально всего 4 МБ. Ни на что другое не осталось бы памяти.   -  person Raymond Chen    schedule 01.05.2020


Ответы (1)


Имейте в виду, что этот дизайн взят из Intel 80386, выпущенного в 1985 году, и с тех пор практически не изменился.

Запись в таблице страниц занимает 4 байта. Если вам нужно 2 ^ 20 записей таблицы страниц, это 4 МБ памяти только для вашей таблицы страниц. Сегодня это может показаться вам разумным, но по меркам 1985 года это возмутительно. В те дни память стоила около 1000 долларов за мегабайт, и большинство людей привыкли к 640 КБ или меньше.

Кроме того, если вы собираетесь использовать многозадачность, которая была основным преимуществом 386, вам потребуется отдельная таблица страниц для каждой задачи. Итак, умножьте эти 4000 долларов на другое большое число; Пользователи Unix уже привыкли к тому, что могут запускать десятки процессов одновременно.

Большинству процессов и близко не понадобилось бы 4 ГБ виртуальной памяти: опять же, вряд ли у кого-то было столько физической памяти или даже дискового пространства. Настоящему пожирателю памяти (может быть, Emacs?) могло понадобиться мегабайт или два. С двухуровневой структурой вам нужно примерно столько записей в таблице страниц, сколько страниц памяти вы фактически используете, плюс немного больше для каталога страниц. Большинство записей каталога страниц не понадобятся и могут быть помечены как неиспользуемые, без необходимости указывать страницу таблицы страниц. Таким образом, вашему ресурсу памяти теперь требуется всего несколько КиБ для подкачки.

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

person Nate Eldredge    schedule 01.05.2020
comment
Сегодня это может показаться вам разумным - 4 МБ таблиц страниц на процесс? Требуется физически непрерывная память? Нет, это по-прежнему неразумно по размеру, и для требования физически непрерывного может потребоваться дефрагментация или специальный список распределителя / свободного места для огромных страниц. - person Peter Cordes; 01.05.2020
comment
@PeterCordes: Спасибо, исправил уровни 3 -> 2. И, конечно же, 4 МБ — это неразумно, но Kids These Days может не устоять. - person Nate Eldredge; 01.05.2020
comment
Также стоит упомянуть, что процессоры могут (и делают) кэшировать страницы directory для ускорения будущих переходов по страницам в том же поддереве. Более ценно для 4-уровневой структуры x86-64 (4x 9-битными уровнями с 8-байтовыми PTE вместо устаревших 32-битных 4-байтовых PTE для 2x 10-битных уровней). Что такое кэш PDE?. И, конечно же, аппаратный обходчик страниц может извлекать данные таблицы страниц через кэш L2 или L1d и получать попадания в кэш, благодаря чему повторяющиеся промахи TLB немного уменьшаются. - person Peter Cordes; 01.05.2020
comment
И эти огромные страницы позволяют вам использовать то, что обычно является PDE, в качестве PTE, которое охватывает весь диапазон того, что обычно является поддеревом: 4 МБ для 32-битных устаревших таблиц страниц, 1 ГБ или 2 МБ для таблиц страниц PAE / x86-64. - person Peter Cordes; 01.05.2020
comment
Я не думаю, что здесь дело в 1985 году, несколько уровней - это то, как вы достигаете разреженности того, что было бы очень длинным массивом. Тогда и сейчас. Один уровень будет очень плохо масштабироваться по мере увеличения ширины адреса. - person Margaret Bloom; 01.05.2020
comment
@MargaretBloom: я думаю, будет справедливо сказать, что разреженные таблицы страниц были абсолютным требованием в 1985 году. В 2020 году это был бы просто плохой дизайн для адресного пространства 4 ГБ (которое любой архитектор ЦП все равно отверг бы). Его все еще можно было бы использовать на практике, если бы кто-то построил ЦП таким образом, а не полным шоу-стоппером. Масштабируемость до более широких адресов — не лучший аргумент; вы все равно измените для более широких физических и / или виртуальных адресов (например, 8-байтовые PTE вместо 4), поэтому, если плоская таблица страниц была хороша конкретно для 386, Intel вполне могла бы это сделать. - person Peter Cordes; 02.05.2020
comment
@MargaretBloom: мне только что пришла в голову ужасная идея, что если бы Intel использовала плоскую таблицу страниц, операционные системы могли бы установить ограничения сегментов, чтобы перехватить доступ к неиспользуемым старшим частям виртуального адресного пространства, чтобы эту часть таблицы страниц можно было использовать для чего-то еще. Очевидным недостатком этого является ограничение структуры виртуального адресного пространства и необходимость использования сегментации. Но это именно тот вид инженерной мысли, связанный с плохим дизайном, который мог бы случиться, если бы архитекторы 386 не были в здравом уме. - person Peter Cordes; 02.05.2020