2
Процессоры X86 и x64 допускают использование 1 ГБ страниц, когда флаг PDPE установлен на CPU. В каком приложении это будет практичным или необходимым и по какой причине?Какие приложения требуют 1 ГБ страниц?
A
ответ
0
Представьте приложение, которое использует огромное количество памяти - Молекулярное моделирование. Прогнозирование погоды, особенно если у него нет взаимодействия с пользователем.
Большие страницы:
(1) уменьшить объем служебной памяти таблицы страниц (2) увеличивает объем памяти, которая может быть сохранена в кэше MMU. (Такое же количество записей кэша ссылается на большую память).
2
Огромная страница поможет в случаях, когда у вас большой объем памяти и схема доступа к памяти занимает большое расстояние (на 4K страницах).
Это не только уменьшает пропуски TLB, но и экономит системные табличные страницы OS mm.
Очень хороший пример обработки пакетов. В приложениях с высокой пропускной способностью (1 Гбит/с или более) пакеты обычно хранятся в пуле буферов пакетов (т. Е. Метод объединения). Например, каждый пакетный буфер имеет размер 2 Кбайт, а пул содержит 512 буферов. Шаблон доступа этого пула буферов пакетов может быть не последовательным (буфер индексируется на 1,2,3,4,5 ...), но скорее случайным с течением времени (1 104 407 455 90 ...). Поскольку нормальный размер страницы составляет 4 КБ, нормальный TLB здесь не поможет, так как каждый доступ к пакету будет иметь пропуски TLB, и на разных страницах будет много разных буферов.
В отличие от этого, если вы положили пул на огромную страницу размером 1 ГБ, тогда все буферы пакетов будут иметь одну и ту же огромную запись в формате TMLB, что позволит избежать промахов.
Это используется в DPDK (Data Development Development Kit), где тариф очень высок, что циклы, потраченные впустую на пропуски TLB, не являются незначительными.
поддержка Hugepage требуется для большого распределения пула памяти, используемой для пакетных буферов (вариант HUGETLBFS должен быть включен в работающего ядра, как указано в предыдущем разделе). Используя огромные расходы , производительность увеличивается, так как требуется меньшее количество страниц, и, следовательно, меньше буферов перевода (TLB, высокоскоростных кэшей перевода ), которые сокращают время, необходимое для перевода адреса виртуальной страницы на адрес физической страницы , Без огромных страниц, высокие тарифы на пропуски TLB произойдут со стандартным размером страницы 4k, замедлением производительности.
http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#bios-setting-prerequisite-on-x86
Другой пример из Oracle:
... почти 6,8 Гб оперативной памяти, используемой для таблиц страниц при hugepages не были настроены ...
... после того, как огромные страницы были выделены и использованы базой данных Oracle.Накладные таблицы страниц был сокращен до чуть меньше 23 MB
http://www.databasejournal.com/features/oracle/understanding-hugepages-in-oracle-database.html
Ссылки по теме:
https://en.wikipedia.org/wiki/Object_pool_pattern
--Edit--
Однако hugepage следует использовать внимательно. Выше я упомянул, что пул памяти выиграет от 1GB огромной страницы. Однако, если у вас есть шаблон доступа даже на границе страницы 1 ГБ, это может не помочь. Существует отличный блог на это:.
0
Я LabView установлен на моем вебе-службе компании Dell с 8 ядрами и 16 Гб DDRM, вождением-24" мониторов
Если я создаю видеопроцессор или наборщик большинство любого типа, с дисплеем 1024px с разрешением 1024px 1024px, LabView резервирует 1,5 ГБ, прежде чем я даже начал компоновку. Он был построен из C и C++.
Я часто храню информацию об изображении в 3D-массивах 256 x 256 x 256 целых чисел U32 которые содержат каждый цвет RGB-пикселя, плюс альфа-канал для непрозрачности или маскировки. Это 64 МБ на каждый уровень буферизованного видео. Если мне нужно запомнить 128 слоев, то это 8 ГБ прямо там.
L abView - это программная langauge, структурированная так же, как программа САПР. Если мне понадобится 8 ГБ для серии видео (HDTV) буферов, это то, что он мне даст, а через несколько секунд ждать, пока malloc выполнит свою работу.
Если бы я создал 3D-массив размером 8 ГБ для базы данных, это было бы совсем иначе, даже если бы я сделал это в MySQL (а не как массив). Для меня, имея много гигабайт бара, чтобы играть, это норма, а не исключение.
Трудно представить какое-либо приложение, где оно может быть * обязательно *. * Beneficial *, вероятно, является лучшим термином - и применяется там, где 1) страница 1 ГБ полностью заполнена или почти такова, что сокращает потраченное впустую пространство, и 2) в таблицах страниц и записях TLB происходит тяжелое оттока - большие страницы означают меньше записей, требуемых в ГБ памяти и, таким образом, снижает давление на аппаратное/программное обеспечение виртуальной памяти. – twalberg
Это просто необычный размер для редких ситуаций. При исследовании я не могу найти ничего, что требует такого большого размера страницы, учитывая, что большинство размеров страницы составляют 4096 байт (по крайней мере по умолчанию). – BugHunterUK