Почему размер страницы Linux (x86) 4 КБ, как это рассчитывается?

Ответ 1

Размер страницы по умолчанию определяется тем, что поддерживает MMU (модуль управления памятью) процессора. В 32-битном защищенном режиме x86 поддерживает два типа страниц:

• нормальные, 4 KiB
• огромные, 4 MiB

Не все процессоры x86 поддерживают большие страницы. Нужно иметь процессор с возможностями расширения размера страницы (PSE). Это исключает процессоры до Pentium. Практически все современные процессоры x86 реализуют его.

4 KiB также широко распространена в деталях в других архитектурах. Можно утверждать, что этот размер происходит от деления 32-битного вирусного адреса на два десятибитовых индекса в каталогах/таблицах страниц, а остальные 12 бит дают размер страницы 4 KiB.

Ответ 2

Дизайн обычного размера страницы размером 4 КБ 32-битной архитектуры на самом деле очень интересен:)

И я хотел бы добавить дополнительный ответ, чтобы показать, почему это разумно.

x86 использует '2-pass' для преобразования адресов виртуальной памяти в адреса физической памяти.

Предположим, что и каталог страниц, и таблица страниц содержат записи , а размер страницы - байт. Чтобы в полной мере использовать адрес , мы имеем:

Каждая запись в каталоге/таблице страниц потребляет 4 байта (32 бит), поэтому:

Таким образом, y = 12, а размер страницы в байтах будет = = 4KB.

А как насчет '1-pass'? Это интересно, потому что логически мы можем использовать одну страницу таблицы для поиска адреса.

Предположим, что каталог страниц содержит записи , каждый из которых отображает адрес на соответствующую страницу, а размер страницы - .

Опять же, чтобы в полной мере использовать адреса , нам нужно:

и

Мы получаем y = 17, а размер страницы = = 128KB.

В любом случае, это работает "логически". Если мы введем TLB, такой большой размер памяти будет диастратом: страницы памяти будут трудно вписываться в TLB, а дизайн выиграл" Эффективность.

Мы также можем утверждать, что в версии "2-pass" каталог страниц и таблица страниц могут иметь разные размеры. Однако это означает, что мы будем использовать более крупный каталог страниц, который будет занимать более одной страницы памяти. К сожалению, каждый раз, когда создается новый пользовательский процесс, для своего собственного каталога страниц ОС приходится выделять последовательные страницы, которые не являются элегантными по дизайну.

Ответ 3

Это зависит от архитектуры процессора.

Размер страницы по умолчанию - 4 КБ на многих архитектурах. Обычно он может быть увеличен (иногда много, например AMD64 1 ГБ), переключившись на огромную страницу. Это позволяет уменьшить таблицу страниц, что может привести к повышению производительности.

Ответ 4

Я получил это из статьи в Википедии, и я цитирую:

Размер страницы обычно определяется архитектурой процессора

Ознакомьтесь с приведенной ниже статьей:

http://en.wikipedia.org/wiki/Page_(computer_memory)

Ответ 5

Введение

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

Atlas стал первым компьютером, поддерживающим пейджинг с размером страницы 3 КБ и оказавшим глубокое влияние на дизайн виртуальную память и мотивированные исследования. Система была разработана между 1958-1962 годами. Интересно отметить, что размер страницы, поддерживаемый 80386, несколько близок к размеру страницы, поддерживаемому Atlas, хотя 80386 был спроектирован около 20 лет спустя, а компьютеры (и рабочие нагрузки, которые они выполняли) радикально изменились в течение этого периода время! Фактически, многие компьютеры того периода использовали размеры страниц, которые варьируются от 0,5 до 5 КБ. Исследователи в то время фактически потратили значительное количество усилий на изучение систем виртуальной памяти (пейджинг и сегментация).

Один из больших вопросов: Каков оптимальный размер страницы? Большое количество работ было опубликовано в 60-х и 70-х годах, которые пытаются изучить и понять влияние размера страницы на производительность приложений и рекомендовать или предоставить рекомендации по выбору размера страницы. Есть, конечно, ряд документов, которые никогда не публиковались. Насколько мне известно, это включает в себя документ от Intel, в котором говорится: "... поэтому размер страницы должен быть 4 КБ". Но факторы, которые влияют или влияют на размер страницы и процесс выбора размера страницы (или нескольких размеров страниц, если на то пошло), хорошо известны, что я и обсужу в этом ответе на базовом уровне. Я также объясню, в частности, почему размер страницы 4 КБ является разумным.

Проблема размера страницы

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

Предположим, что страница состоит из N bytes ² (что подразумевает, что кадр страницы также определяется размером N байтов по определению) и рассматривает виртуальное адресное пространство, состоящее из P страницы (т.е. номера страниц {0, 1, 2,..., P - 1}, а общее количество виртуальных адресов N * P). Предположим также, что физическое адресное пространство состоит из F кадров страницы (то есть номера страниц страницы: {0, 1, 2,..., F - 1}, а общее число физических адресов N * F).

Для виртуального адреса VA требуется механизм (устройство отображения) для определения физического адреса, PA, он отображается или возникает ошибка страницы, если он не был отображен. Устройство сопоставления использует структуру данных (таблицу страниц), хранящуюся где-нибудь, для выполнения сопоставления. Должна быть запись в этой таблице для каждой выделенной виртуальной страницы, которая описывает, как будет отображаться страница, и потенциально некоторые дополнительные атрибуты (такие как атрибуты защиты). Конструкция записи в таблице страниц, как вы увидите, взаимодействует с размером страницы. Я расскажу о дизайне записи таблицы страниц в Intel 80386 позже.

Размер виртуального адреса - log ₂ (N * P), а размер физического адреса - log ₂ (N * F). Некоторые биты VA будут представлять смещение внутри страницы, в то время как другие биты будут представлять номер страницы, который идентифицирует страницу с помощью устройства отображения.

Сколько у нас параметров для размера страницы? Ну, это может быть немного меньше одного байта до N * P или N * F, в зависимости от того, что меньше. Это много вариантов.

Удобно, чтобы размер страницы составлял 2

Виртуальный адрес VA эквивалентен паре номера страницы и смещения (PN, OFF). Процесс перевода должен быть максимально эффективным. Это удобно для программистов ³ чтобы байты внутри страницы были смежными в адресном пространстве. Таким образом, адреса элементов в многобайтовой структуре данных могут быть вычислены с простой арифметикой по одному адресу, который будет составлять базовый адрес структуры данных. Это может быть достигнуто с использованием наименее значимого журнала ₂(N) бит (округленный) виртуального адреса для представления смещения и остальных битов для представления номера страницы.

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

Во всяком случае, имея в виду, что выбор страниц размером 4 КБ был сделан в 80-е годы, такие крайне незначительные вариации в размерах страниц были показаны (как теоретически, так и экспериментально), чтобы иметь мало значения. Таким образом, восторжествовало удобство размеров страницы размером с 2 страницы. Это уменьшает количество размеров страниц для экспоненциального рассмотрения. Но у нас все еще есть хороший выбор.

Внесение меньших размеров страниц

Поскольку устройство отображения работает на уровне страниц, единица распределения с точки зрения операционной системы представляет собой виртуальную страницу ⁴. Даже если приложение должно выделять только 1 байт, оно все равно должно сказать ОС, чтобы выделить целую виртуальную страницу для этого 1 байта. Эта проблема называется внутренней фрагментацией. Каждое приложение (или, возможно, даже каждый компонент приложения) имеет свое виртуальное адресное пространство, из которого он выделяет память в блоках размера страницы. Он ожидал от каждого приложения не использовать одну страницу для отдельного объекта, который он выделяет, а скорее выделяет как можно больше объектов с одной страницы, прежде чем выделяет больше страниц. Однако, поскольку атрибуты страницы работают на уровне страниц, одно и то же приложение может использовать несколько менеджеров памяти в режиме пользовательского режима (например, при использовании нескольких сеансов управления C/С++), и для приложения сложно совместно использовать части страниц, которые они не используют с другими приложениями внутренняя фрагментация может возникать на многих страницах системы. Использование меньших размеров страниц может помочь уменьшить количество потерянных физических (для всей системы) и виртуальной (для каждого процесса) памяти.

Кроме того, обычно приложения проходят через несколько этапов на протяжении всей их жизни, где они демонстрируют разные требования к памяти на разных этапах. Если размер страницы составляет, скажем, 16 Кбайт, но для многих их фаз многие приложения могут потребовать меньше 10 КБ, тогда будет много потерянной физической памяти, что может привести к ситуациям с нехваткой памяти, которые могут иметь были предотвращены, если поддерживались меньшие размеры страниц, например 8 или 4 КБ.

Меньшие размеры страниц предпочтительнее для обработки ошибок со страницы "копирование на запись", поскольку чем меньше страница, тем меньше времени для ее создания. Для чрезвычайно малых размеров страниц это может не повлиять на измеримую разницу в зависимости от ширины полосы пропускания памяти.

Типичные объемы физической памяти, доступные на компьютерах 70-х годов, были в диапазоне 10 или 100 с КБ. Было бы бессмысленно иметь размеры страниц сотен КБ или больше. Фактически, рабочие группы приложений в то время обычно составляли всего несколько или десятки КБ. Поэтому даже размеры страниц размером до 16 КБ вряд ли будут практичными, потому что только пара страниц может потреблять всю доступную физическую память. Размер страницы должен быть согласован с объемом физической памяти. Этот аргумент, конечно, может быть применен к сегодняшним системам (не имеет смысла иметь 128-Гбайт страниц, например).

Поэтому, учитывая размеры рабочих наборов и доступность физической памяти 70-е и начало 80-х годов, размер страницы должен быть равен 2 в диапазон 2 ⁰ -2 ¹⁴. Круто, теперь у нас есть только 15 вариантов.

Внесение больших размеров страниц

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

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

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

Пространственная локальность ссылок поощряет использование определенных размеров страниц. При очень небольших размерах страниц очень вероятно, что все байты на странице будут использоваться в течение небольшого периода времени. По мере увеличения размера страницы увеличивается количество байтов, которые с меньшей вероятностью будут использоваться. Однако для очень больших страниц весь рабочий набор может помещаться на небольшое количество страниц независимо от местоположения. Поэтому, чтобы свести к минимуму количество ошибок страницы, размер страницы должен быть слишком маленьким или слишком большим, но не посередине. Но в конечном итоге это варьируется от одного приложения к другому. Новые парадигмы программирования, такие как объектно-ориентированное программирование и функциональное программирование, а также такие методы, как многопоточность, могут фактически уменьшить пространственную локальность из-за широкого использования связанных структур и из-за взаимодействия друг с другом приложения. Большие размеры страниц предпочтительнее, чтобы уменьшить количество ошибок страницы. Тем не менее, меньшие размеры страниц могут быть лучше для памяти, разделяемой между несколькими приложениями, для уменьшения внутренней фрагментации разделяемых страниц. Экспериментально также показано, что количество кадров страниц, которые могут храниться в основной памяти, коррелирует с количеством ошибок страницы, что способствует меньшим размерам страницы.

Потребность в TLB была хорошо известна в то время. Intel назвала их кэшами страниц в своих патентах (не уверен, что Intel впервые использовала этот термин). Быстрые TLB очень важны, потому что перевод адресов находится на критическом пути выполнения инструкций. Чтобы сделать их как можно быстрее, они должны быть крошечными, но тогда они могут кэшировать небольшое количество записей в таблице страниц. Это мотивирует использование больших размеров страниц.

В поиске оптимального размера страницы оказывается, что его нет. В то время было известно, что существует необходимость в поддержке нескольких размеров страниц. Фактически, система Multics, разработанная в 1965 году, поддерживала 64- или 1024-страничные страницы (слово имеет размер 36 бит). Показано, что размеры страниц в диапазоне 2 ⁷ -2 ¹⁴ являются оптимальными как эмпирически, так и теоретически в разных сценариях. Intel, должно быть, заметила, что страницы с 4 КБ приводят к лучшей средней производительности для приложений, которые их клиенты использовали в 80-х годах. На сегодняшний день компьютеры и приложения, такие крошечные различия в размерах страниц не делают как это было в 70-х и 80-х годах.

Конструкция таблицы страниц Ввод Intel 80386

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

Размер страницы ближайшего будущего

В результате поддержки отображения страницы 64 КБ в 4 КБ подстраницы, VA64 напрямую поддерживает все текущие операции на 4 KB страниц, включая независимые защитные биты на страницу 4 КБ и произвольные сопоставления адресов в 4 КБ. VA64 также поддерживает ядро ​​ОС управление страницами на границах 4 КБ, даже когда ядро ​​ОС выделяет память в 64 КБ. В результате поддержки больших страниц VA64 поддерживает все разделы диапазона виртуальных адресов на страницах, которые существующая пейджинговая система, такая как пейджинг Intel Corporation IA-32e поддержка системы. Поэтому VA64 поддерживает приложения и оборудование устройства, которые работают с ядром ОС Windows® на 4 КБ, а также используя в полной мере страницы 64 КБ, когда можно использовать страницы с 64 КБ.

Возможности VA64 могут быть постепенно приняты ядром ОС, а не требовать их поддержки в первом поколении VA64-совместимое ОС. Например, ядро ​​ОС, поддерживающее VA64, может начните с сопоставления всех страниц с текущими размерами (например, 4 КБ /2 ГБ/1 ТБ в Система пейджинга Intel Corporation IA-32e), но переход на новую страницу формат таблицы. После изменения формата таблицы страниц ядро ​​ОС может быть изменен для сопоставления виртуальной памяти в 64 КБ единиц и изменения храните 64 КБ страниц в своем бесплатном списке. Тогда ядро ​​ОС могло бы начать используя страницы размером 64 КБ, когда позволяют выравнивание и защита, и добавьте поддержка других возможностей VA64.

Я ничего не знаю о пейджинговой системе VA64, кроме того, что написано в патенте. В Интернете нет ничего в Интернете. Думаю, мы скоро узнаем.

Выбранные ссылки

Denning, P.J. (1970). Виртуальная память. ACM Computing Surveys Volume 2 Issue 3, 153-189.

Gelenbe, E., Tiberio, P., and Boekhorst, J. C. A. (1973). Размер страницы в системах пейджинга спроса. Acta Informatica, 3 (1), 1-23.

Аланко, Т. О. и Веркамо А. I. (1983). Сегментация, подкачки и оптимальные размеры страниц в виртуальной памяти. Оценка эффективности, 3 (1), 13-33.

Corbató, F. J., and Vyssotsky, V. A. (1965). Введение и обзор системы Multics. В трудах 30 ноября - 1 декабря 1965 года осенью состоялась совместная компьютерная конференция, часть я (стр. 185-196).

Сноски

(1) Фактически размер одной виртуальной страницы может быть кратным размеру кадра страницы, но не оставляйте его там.

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

(3) Возможно, не программисты, в зависимости от языка программирования, а компиляторы, компоновщики, сборщики и инструменты, которые работают с двоичным кодом.

(4) Конечно, можно создать систему, которая поддерживает одновременное использование подкачки и непайпинга, тем самым потенциально поддерживая несколько единиц распределения, но не оставляйте их там.

Ответ 6

Я добавляю этот ответ/комментарий, потому что вычисление sleepsort очень интересно, я должен добавить его на мою веб-страницу (с указанием источника, конечно). Ответ (возможный) на вопрос о том, как можно вычислить программный код, можно найти here. То, как оно рассчитывается, как упоминалось сна, очень интересно. Я сделал то же самое для x86_64, и результат не был тем, что я ожидал. Однако дальнейшее чтение на управлении памятью x86_64 Я обнаружил, что для 64-битного Intel 16 бит не используются, оставьте его 48 бит для вычисления. 9 бит для ветвей дерева памяти, каждая ветвь еще 9 бит, здесь в другом 9 для ветвей и, наконец, 9 бит для листьев последней ветки. Таким образом, 48 - 36 = 12 бит для каждого адреса на странице памяти. 2 ^ 12 = 4096, как упоминалось ранее сна. Я просто задаюсь вопросом, сколько пройти эту архитектуру, 3 или 4 (если кто-нибудь может это объяснить) следующий расчет сна:

2^x * 2^x * 2^x * 2^x * 2^y = 2^48
4x + y = 48

this time we have 8 bytes for each address (8 bytes * 8 bits / byte = 64 bits)

2^y / 2^3 = 2^x
y - 3 = x
filled in in previous equation:

4(y - 3) + y = 48
4y - 12 + y = 48
5y = 60
y = 12
because 2^y represents the pagesize, the size = 2^12 = 4096 bytes

Оставьте мне вопрос "а как насчет этих огромных страниц в Linux"?