Transparent Hugepages: детали
В первой части "Введение в Transparent Hugepages" я коротко рассказал что такое Transparent Hugepages, сейчас расскажу почему нужно использовать большие страницыВ Linux память состоит из так называемых страниц. Страница это наименьшая единица памяти. Вся память поделена на страницы одинакового размера. Размер страницы может варьироваться в зависимости от аппаратной архитектуры, например для x86 размер страницы будет 4KB, для ia64 = 8KB, для ppc64 размер страницы может быть как 4KB так и 8KB и 64KB.
Как известно в системе установлена физическая память вполне конкретного размера, например 4GB. Приложения никогда не обращаются напрямую к памяти. Блоки физической памяти называются страничными фреймами (page frame). Приложения обращаются в виртуальную память, для программ всегда выделяется (allocate) только блоки виртуальной памяти. Виртуальный блок памяти как раз и называется страницей. Каждая страница в виртуальной памяти транслируется в определенный страничный фрейм. Таким образом приложения использующие виртуальную память на самом деле используют блоки физической памяти.
Также существуют страничные таблицы (page table) в которых хранится отображение виртуальных адресов в физические адреса. Эти таблицы также хранятся в памяти. Поиск адресов необходимых страниц в этих таблицах называется страничным просмотром (page walk). Существует несколько табличных страниц и чтобы добраться до нужного адреса физической страницы, как правило нужно просмотреть несколько таблиц. Таким образом каждый доступ к памяти требует просмотра страничных таблиц (page walk). Обычно табличный просмотр выполняется от 10 до 100 тактов системного таймера.
Очевидным вариантом оптимизации кажется кэширование результатов табличных просмотров. На помощь приходит TLB (Translation Look-aside Buffer) это специальный кэш используемый для ускорения трансляции адресов виртуальной памяти в адреса физической памяти. TLB содержит фиксированный набор записей. Каждая запись содержит соответствие адреса страницы виртуальной памяти адресу физической памяти. Если адрес отсутствует в TLB, процессор обходит таблицы страниц и сохраняет полученный адрес в TLB, что занимает в 10-60 раз больше времени, чем получение адреса из записи, уже закэшированной TLB. Стоит отметить что вероятность промаха TLB (TLB miss) невысока и составляет в среднем от 0,01 % до 1 %.
TLB является ассоциативной памятью типа CAM (content addressable memory) она весьма дорогая и ее использование накладывает некоторые ограничения, например TLB может хранить до 1024 записей и еще очень затратным ограничением является необходимость сброса TLB при каждом переключении контекста. Переключение контекста (context switch) — процесс прекращения выполнения процессором одной задачи (процесса, потока, нити) и переход к выполнению другой задачи. При это происходит сохранение всей необходимой информации и состояния прерванной задачи и восстановление состояния задачи, к выполнению которой переходит процессор. Но при своих недостатках TLB кэш является очень быстрым. Таким образом TLB это дефицитный ресурс и каждая попытка его использования должна быть максимально эффективной.
Теперь возьмем пример приложение базы данных где объем обрабатываемых данных 16GB. Получается приблизительно 4.1 млн. страниц и страничная таблица размеров 15GB. С таким приложением использование стандартных страниц (4KB) дает высокие накладные расходы на управление такими страницами. При этом TLB кэш может поместить в себя до 1024 записей, а это очень мало и возникает большой просад в производительности.
И здесь мы подходим к необходимости использования Hugepages. Hugepages это страницы большего размера, в архитектуре x86 это страницы размером 2MB. Несложно посчитать что одна такая страница соразмерна 512 стандартным страницам. Таким образом в каждую запись TLB кэша может вмещаться адресация на 512 обычных страниц. Следовательно увеличивается процент успешных попаданий в TLB (TLB hit) и уменьшается количество страниц которыми нужно как-то управлять.
Сравнивая с прошлым примером выходит что для нашего приложения необходимо 8192 больших страниц (действительно не много в сравнении с 4.1 млн в прошлом примере).
Это большой прогресс.
Говоря о применении Hugepages стоит отметить несколько моментов:
- Hugepages следует резервировать перед использованием
- Не все приложения могут работать с Hugepages
- Большие страницы не могут попадать в подкачку, они остаются заблокированными в памяти.
Поэтому нужно находить баланс между:
- стандартные страницы дают накладные расходы на управление
- большие страницы дают фрагментацию в памяти
- THP основывается на ограничениях Hugepages
- THP может быть использовано по умолчанию для всех приложений
- THP является прозрачным слоем для приложений - им необязательно знать про THP
- Все приложения выигрывают от использования THP
- Прирост производительности в общем случае составляет около 10%
- Transparent Hugepages выделяются при необходимости (существует заранее определенный пул откуда берутся большие страницы)
- THP могут попадать в подкачку (при этом страница разбивается на множество стандартных 4KB страниц)
- Поток ядра khugepaged сканирует запущенные процессы и пытается переключить их с использования нормальных страниц на большие
- THP старается по максимуму использовать Hugepages
- Ядро самостоятельно транслирует свою память используя Hugepages.
На главную "Virtualizing Linux"
Комментариев нет:
Отправить комментарий