Огромное количество "dTLB-load-misses" при тесте пересылки DPDK - PullRequest
0 голосов
/ 29 августа 2018

В последнее время я пытаюсь выполнить тест пересылки с помощью приложения DPDK "testpmd". И я нахожу что-то интересное.

Когда для TX и RX используются 512 дескрипторов, производительность выше, чем при использовании 4096 дескрипторов. После проверки счетчиков с помощью команды "perf" я обнаружил, что наблюдается огромное количество " dTLB-load-misses ". И это примерно в 100 раз больше с 512 дескрипторами. Но сбои страниц всегда равны нулю. С аргументами ": u" и ": k" кажется, что большинство пропусков TLB находятся в пространстве пользователя. Все буферы находятся на одной огромной странице для хранения данных сетевых полезных нагрузок, а размер огромной страницы составляет 512 МБ. Каждый буфер менее 3 КБ. Буфер и дескрипторы являются однозначным отображением.

Так есть ли какая-нибудь подсказка, что я могу найти огромное количество пропусков TLB? И повлияет ли это на производительность? (Ухудшение)

Спасибо

1 Ответ

0 голосов
/ 29 августа 2018

Как правило, объем кэша TLB процессора зависит от размера страницы. Это означает, что для страниц размером 4 КБ и для страниц объемом 512 МБ могут быть разные записи L1 / L2 кэша TLB.

Например, для ARM Cortex-A75:

Микро TLB данных - это полностью ассоциативный TLB с 48 записями, который используется операциями загрузки и хранения. Записи кэша имеют гранулярность 4 КБ, 16 КБ, 64 КБ и 1 МБ только для сопоставлений VA и PA.

Источник: Информационный центр ARM

Для ARM Cortex-A55:

TLB данных Cortex-A55 L1 поддерживает только страницы размером 4 КБ. Любые другие размеры страниц разрушаются после TLB L2, и соответствующий размер страницы отправляется в TLB L1.

Источник: Информационный центр ARM

По сути, это означает, что огромные отображения страниц размером 512 МБ будут разбиты до некоторого меньшего размера (до 4 КБ), и только те небольшие фрагменты будут кэшироваться в L1 dTLB.

Таким образом, даже если ваше приложение помещается на одной странице объемом 512 МБ, производительность все равно будет зависеть от фактического объема памяти.

...