Эта статья, по логике, должна была появиться первой, до статьи о Прозрачный обмен страницами , поскольку это база, с которой должно начинаться погружение в управление ресурсами памяти в vSphere 4.1. На моем английском блог Когда я впервые начал изучать эту тему, я разделил ее на две части — мне было легче воспринимать совершенно новую для меня информацию.
Но так как публика на хабе серьезная и опытная, я решил объединить материал в одну статью.
Начнем с самого основного элемента, который называется Страница памяти .
Он определяется как непрерывный блок данных фиксированного размера, используемый для распределения памяти.
Обычно размер страницы может составлять 4 КБ (маленькая страница) или 2 МБ (большая страница).
ОС выделяет каждому приложению 2 ГБ виртуальной памяти, принадлежащей только этому приложению.
Чтобы ОС могла знать, какая страница физической памяти (Физический адрес — PA) соответствует определенной странице виртуальной памяти (Виртуальный адрес — VA), ОС отслеживает все страницы памяти с помощью Таблица страниц .
Здесь хранится вся переписка между ВА и ПА.
Далее нам понадобится какой-то инструмент, который сможет по запросу приложения памяти найти нужную пару VA — PA в Таблице страниц.
Этот инструмент называется блоком управления памятью (MMU).
Процесс поиска пары VA-PA не всегда может быть быстрым, учитывая, что в виртуальном адресном пространстве размером 2 ГБ может находиться до 524 288 страниц по 4 КБ.
Чтобы ускорить этот вид поиска, MMU активно использует буфер поиска трансляции (TLB), в котором хранятся недавно использованные пары VA-PA. Каждый раз, когда приложение делает запрос памяти, MMU сначала проверяет TLB, чтобы увидеть, есть ли там пара VA-PA. Если он есть, отлично, процессору передается PA — это называется попаданием TLB. Если в TLB ничего не найдено (промах TLB), то MMU должен прочесать всю Таблицу страниц и, как только нужная пара будет найдена, поместить ее в TLB и сообщить приложению, что оно может отправить запрос.
снова.
Если нужная страница находится в свопе, то сначала страница отправляется из свопа обратно в память, затем пара VA-PA записывается в TLB и только потом приложение осуществляет доступ к памяти.
Визуально это выглядит так 
Размер TLB существенно ограничен.
В процессорах Nehalem TLB первого уровня содержит 64 записи страниц по 4 КБ или 32 записи страниц по 2 МБ, TLB второго уровня может работать только с небольшими страницами и содержит 512 записей.
Исходя из этого, можно предположить, что использование больших страниц приведет к существенно меньшему количеству промахов TLB — (64x4=256)+(512x4=2048)=2304 КБ против 32x2=64 МБ.
Не могу не перечислить стоимость промаха TLB из Википедии, где считается некий средний TLB. Размер: 8–4096 записей.
Время попадания: 0,5 — 1 такт. Штраф за промах: 10–100 тактов.
Процент промахов: 0,01 – 1% Если попадание TLB выполняется за один цикл ЦП, промах TLB занимает 30 тактов, а если средняя частота промахов TLB составляет 1%, то среднее количество циклов на запрос памяти составляет 1,30. Все эти аргументы и расчеты справедливы для ситуаций, когда наша ОС работает на физическом сервере.
Но в случае, когда ОС работает на виртуальной машине, мы имеем другой уровень трансляции памяти.
Когда приложение на виртуальной машине делает запрос памяти, оно использует виртуальный адрес (VA), который необходимо преобразовать в физический адрес виртуальной машины (PA), который, в свою очередь, должен быть преобразован в адрес физической памяти хоста ESXi (HA).
).
То есть нам уже нужны две Таблицы Страниц: одна для пар VA-PA, другая для трансляций PA-HA. Если мы попытаемся отобразить это графически, то получим примерно следующее.
Я не хочу углубляться в глубокие исторические дебри технологий виртуализации памяти на заре ESX, поэтому мы рассмотрим последние две — Software Memory Virtualization и Hardware Assisted Memory Virtualization. Здесь мне нужно ввести в нашу историю еще один элемент Virtual Machine Monitor (VMM).
VMM участвует в выполнении всех команд, которые виртуальная машина выдает процессору и памяти.
Для каждой виртуальной машины существует отдельный процесс VMM. Теперь, когда мы изучили основы, мы можем перейти к некоторым деталям.
Программная виртуализация памяти Итак, как следует из названия, перед нами программная реализация виртуализации памяти.
В этом случае VMM создает таблицу теневых страниц, в которую копируются следующие переводы: 1. VA - PA, эти пары адресов напрямую копируются из Таблицы страниц виртуальной машины, за содержимое которой отвечает гостевая ОС.
2. PA - HA, за эти пары адресов отвечает сам VMM То есть это своего рода сводная таблица двойного перевода.
Каждый раз, когда приложение в виртуальной машине обращается к памяти (VA), MMU должен просмотреть таблицу теневых страниц и найти соответствующую пару VA – HA, чтобы физический процессор мог работать с реальным физическим адресом памяти хоста (HA).
.
Это изолирует MMU от виртуальной машины, так что одна виртуальная машина не получает доступа к памяти другой виртуальной машины.
Согласно документации VMware, этот тип трансляции адресов по скорости вполне сравним с трансляцией адресов на обычном физическом сервере.
Возникает вопрос, а зачем тогда суетиться и изобретать новые технологии? Оказывается, в этом есть что-то — не все типы запросов к памяти у виртуальной машины могут выполняться с той же скоростью, что и на физическом сервере.
Например, каждый раз, когда происходит изменение Таблицы страниц в ОС виртуальной машины (то есть меняется пара VA — PA), VMM должен перехватить этот запрос и обновить соответствующий раздел Теневой Таблицы Страниц (то есть, получившаяся пара ВА - НА).
Еще один хороший пример — когда приложение делает свой первый запрос к определенной ячейке памяти.
Поскольку VMM еще ничего не слышал об этом ВА, это означает, что в Shadow Page Table необходимо создать новую запись, тем самым снова внося задержку доступа к памяти.
И наконец, хотя это и не критично, можно отметить, что сама Shadow Page Table тоже потребляет память.
Эта технология применима к vSphere, работающей на процессорах, выпущенных до выхода на рынок семейств Nehalem/Barcelona. Аппаратная виртуализация памяти В настоящее время на рынке существуют две основные технологии виртуализации MMU. Первая была представлена Intel в семействе процессоров Nehalem, и эта новая функция называется расширенными таблицами страниц (EPT).
Второй был представлен AMD в семействе процессоров Barcelona под названием Rapid Virtualization Indexing (RVI).
В принципе обе технологии выполняют один и тот же функционал, а отличаются лишь очень глубоко техническими деталями, изучением которых я пренебрег ввиду их незначительности для моей работы.
Итак, главное преимущество обеих технологий в том, что теперь новый MMU может одновременно запускать два процесса поиска адресов в Таблицах страниц.
Первый процесс ищет пару VA-PA в таблице страниц вашей виртуальной машины, другой процесс ищет пару PA-HA в таблице страниц, управляемой VMM. Вторая таблица страниц называется расширенной (иногда вложенной) таблицей страниц.
Как только обе пары найдены, MMU записывает полученную пару VA-PA в TLB. Поскольку обе таблицы теперь доступны MMU, больше нет необходимости поддерживать таблицу теневых страниц.
Еще один важный момент заключается в том, что теперь, когда обе таблицы отделены друг от друга, виртуальная машина может легко управлять своей таблицей страниц без контроля со стороны VMM. Еще одно существенное отличие в архитектуре Nehalem заключается в том, что в TLB теперь введено новое поле идентификатора виртуального процессора.
На старых процессорах этого поля не было, и при переключении процессора из контекста одной виртуальной машины в контекст другой виртуальной машины все содержимое TLB удалялось из соображений безопасности.
Теперь с помощью VPID этого можно избежать и, соответственно, опять же уменьшить количество случаев промахов TLB. Единственная отмеченная проблема этого решения — более высокая стоимость промаха TLB по одной простой причине — каждый раз, когда MMU не находит требуемую пару адресов MMU в TLB, MMU приходится снова искать в двух таблицах.
Вот почему, когда vSphere обнаруживает, что она работает на процессоре Nehalem, она обязательно использует большие страницы.
На следующей неделе я постараюсь закончить отключение поддержки больших страниц на всех наших ESXi-хостах и опубликую результаты производительности — в моем первом статья Я уже упоминал о результатах отключения больших страниц на одном из рабочих серверов.
По ряду причин, от лени и попытки сделать материал более доступным по моему незнанию, я упустил довольно много разных нюансов и подробностей.
Например, такие как разные типы TLB и процессоров, дополнительный уровень трансляции памяти из Linear Address в Virtual Address, различия в работе с памятью в разных ОС и т.д. Критика качества материала, технические неточности, каверзные вопросы, и вообще любой живой интерес приветствуется, ведь они помогут нам всем восполнить собственные пробелы в знаниях.
Моими главными источниками вдохновения и информации были Википедия и вот эта.
документ , за что хотелось бы сказать огромное спасибо их авторам.
Теги: #Виртуализация #vsphere 4.1 mmu tlb Nehalem
-
Советы По Выбору Агрегатора Новостей Rss
19 Oct, 24 -
Паттерны Ci/Cd И Антипаттерны. Часть 1
19 Oct, 24 -
Ice Cream Sandwich Запущен На Kindle Fire
19 Oct, 24 -
Мультиплеер В Играх: Взгляд Изнутри
19 Oct, 24
