Какой будет точный код для подсчета количества пропущенных кэш-памяти последнего уровня в архитектуре 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.

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

Источник

1 ответ

Решение

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

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

  • Библиотека Джевентса Энди Клина, которая, помимо прочего, позволяет вам читать события PMU из пространства пользователя. Я лично не использовал эту часть pmu-tools, но материал, который я использовал, был высокого качества. Кажется, он использует существующие системные вызовы perf_events для программирования счетчиков, поэтому ему не нужна модель ядра.
  • Библиотека libpfc представляет собой реализацию модуля ядра и пользовательского кода с нуля, которая позволяет считывать счетчики производительности в пользовательском пространстве. Я использовал это, и это работает хорошо. Вы устанавливаете модуль ядра, который позволяет программировать PMU, а затем используете API, предоставляемый libpfc, для чтения счетчиков из пространства пользователя (вызовы сводятся к rdpmc инструкции). Это самый точный и точный способ считывания счетчиков, и он включает в себя функцию "вычитания служебной информации", которая может дать вам истинные значения PMU для измеренной области путем вычитания событий, вызванных самим кодом чтения PMU. Вам нужно привязать к одному ядру, чтобы подсчеты имели смысл, и вы будете сфальсифицировать результаты, если ваш процесс будет прерван.
  • Открытая библиотека Intel Processor Counter Monitor. Я не пробовал это в Linux, но я использовал его предшествующую библиотеку, очень похожий по названию 1 Performance Counter Monitor в Windows, и он работал. В Windows ему нужен драйвер ядра, но в Linux кажется, что вы можете либо использовать диск, либо пройти через него. perf_events,
  • Используйте функциональность Marker API библиотеки likwid. Likwid был вокруг некоторое время и кажется хорошо поддержанным. Я использовал likwid в прошлом, но только для измерения целых процессов в вопросе, аналогичном perf stat а не с маркером API. Чтобы использовать API-маркер, вам все равно нужно запустить процесс как дочерний элемент процесса измерения likwid, но вы можете программно считывать значения счетчиков внутри вашего процесса, что вам и нужно (насколько я понимаю). Я не уверен, как likwid настраивает и читает счетчики, когда используется API-маркер.

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

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

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

Источник

Я бы использовал PAPI, см. http://icl.cs.utk.edu/PAPI/ Это кроссплатформенное решение, которое пользуется большой поддержкой, особенно со стороны сообщества hpc.

Источник
Другие вопросы по тегам