Какой будет точный код для подсчета количества пропущенных кэш-памяти последнего уровня в архитектуре Intel Kaby Lake

Question

Какой будет точный код для подсчета количества пропущенных кэш-памяти последнего уровня в архитектуре Intel Kaby Lake

Я прочитал интересную статью, озаглавленную «Атака по боковому каналу с высоким разрешением на кэш последнего уровня», и хотел найти функцию хеширования индекса для моей собственной машины, то есть Intel Core i7-7500U (архитектура Kaby Lake) — следуя указаниям из этой работы.

Для обратного инжиниринга хеш-функции в документе упоминается первый шаг:

 for (n=16; ; n++)
{
// ignore any miss on first run
for (fill=0; !fill; fill++)
{
// set pmc to count LLC miss
reset_pmc();
for (a=0; a<n; a++)
// set_count*line_size=2^19
load(a*2^19);
}

// get the LLC miss count
if (read_pmc()>0)
{
min = n;
break;
}
}

Как я могу кодировать reset_pmc() а также read_pmc() в С ++? Из всего, что я читал онлайн, я думаю, что для этого требуется встроенный код ассемблера, но я понятия не имею, какие инструкции использовать, чтобы получить количество пропусков LLC. Я был бы обязан, если бы кто-то мог указать код для этих двух шагов.

Я использую Ubuntu 16.04.1 (64-разрядная версия) на рабочей станции VMware.

П.С .: Я нашел упоминание об этих LONGEST_LAT_CACHE.REFERENCES а также LONGEST_LAT_CACHE.MISSES в главе 18 тома 3В Руководство разработчика программного обеспечения Intel Architectures, но я не знаю, как их использовать.

7

c++caching perf reverse-engineering x86

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Ты можешь использовать perf как предложил Коди для измерения событий извне кода, но я подозреваю из вашего примера кода, что вам нужен детальный, программный доступ к счетчикам производительности.

Для этого вам нужно включить считывание счетчиков в пользовательском режиме, а также иметь возможность их программировать. Так как это ограниченные операции, для этого вам понадобится хотя бы некоторая помощь от ядра ОС. Собрать собственное решение будет довольно сложно, но, к счастью, есть несколько существующих решений для Ubunty 16.04:

Энди Клин библиотека Джевентса, который, помимо прочего, позволяет читать события PMU из пространства пользователя. Я лично не использовал эту часть pmu-tools, но материал, который я использовал, был высокого качества. Кажется, использовать существующие perf_events syscalls для программирования счетчиков, поэтому и не нуждается в модели ядра.
libpfc библиотека — это реализация с нуля модуля ядра и пользовательского кода, позволяющая считывать пользовательские счетчики производительности. Я использовал это, и это работает хорошо. Вы устанавливаете модуль ядра, который позволяет программировать PMU, а затем используете API, предоставляемый libpfc, для чтения счетчиков из пространства пользователя (вызовы сводятся к rdpmc инструкции). Это самый точный и точный способ считывания счетчиков, и он включает в себя функцию «вычитания служебной информации», которая может дать вам истинные значения PMU для измеренной области путем вычитания событий, вызванных самим кодом чтения PMU. Вам нужно привязать к одному ядру, чтобы подсчеты имели смысл, и вы будете сфальсифицировать результаты, если ваш процесс будет прерван.
Intel с открытым исходным кодом Монитор счетчика процессора библиотека. Я не пробовал это в Linux, но я использовал его предшественницу, библиотеку с очень похожим названием¹ Монитор счетчика производительности на винде, и это сработало. В Windows ему нужен драйвер ядра, но в Linux кажется, что вы можете либо использовать диск, либо пройти через него. perf_events,
Использовать likwid библиотеки API-маркер функциональность. Likwid был вокруг некоторое время и кажется хорошо поддержанным. Я использовал likwid в прошлом, но только для измерения целых процессов в вопросе, аналогичном perf stat а не с маркером API. Чтобы использовать API-маркер, вам все равно нужно запустить процесс как дочерний элемент процесса измерения likwid, но вы можете программно считывать значения счетчиков внутри вашего процесса, что вам и нужно (насколько я понимаю). Я не уверен, как likwid настраивает и читает счетчики, когда используется API-маркер.

Таким образом, у вас есть много вариантов! Я думаю, что все они могли бы работать, но я могу лично поручиться за libpfc так как я сам использовал его для той же цели в Ubuntu 16.04. Проект активно развивается и, пожалуй, самый точный (с наименьшими накладными расходами) из вышеперечисленного. Так что я бы, наверное, начал с этого.

Все вышеперечисленные решения должны быть в состоянии работать для Kaby Lake, поскольку функциональность каждой последующей «Архитектуры мониторинга производительности», как правило, является расширенной версией предыдущего, и API в целом сохраняется. В случае libpfcОднако автор имеет ограниченный это только для поддержки архитектуры Haswell (PMA v3), но вам просто нужно изменить одна строка кода локально, чтобы исправить это.

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

6