Почему perf не сообщает "промахи dcache-store-misses"? - PullRequest
Новая
       71

Почему perf не сообщает "промахи dcache-store-misses"?

0 голосов
/ 09 июля 2020

Я использую perf для сбора некоторых показателей своего кода, и я запускаю следующую команду: 

sudo perf stat -e L1-dcache-load-misses,L1-dcache-store-misses ./progB

L1-dcache-load misses работает хорошо, но L1-dcache-store-misses всегда возвращает это: 

<not supported>      L1-dcache-store-misses

Что я делал не так?

1 Ответ

0 голосов
/ 14 июля 2020

Perf печатает <not supported> для общих c событий, которые были запрошены пользователем или набора событий по умолчанию (в perf stat), которые не сопоставлены с реальными аппаратными событиями PMU на текущем оборудовании. Ваше оборудование не соответствует событию L1-dcache-store-misses generi c, поэтому perf сообщает вам, что ваш запрос sudo perf stat -e L1-dcache-load-misses,L1-dcache-store-misses ./progB не может быть полностью реализован на текущей машине.

Ваш процессор "Продукт ранее Kaby Lake ", который имеет Skylake PMU в соответствии с linux файл ядра arch/x86/events/intel/core.c: 

#L4986
case INTEL_FAM6_KABYLAKE:
    memcpy(hw_cache_event_ids, skl_hw_cache_event_ids, sizeof(hw_cache_event_ids));

Строка 420 этого файла представляет собой отображение событий кэша (generi c имя события perf в соответствии с реальным кодом события hw pmu) для skylake pmu - skl_hw_cache_event_ids, а ваш промах загрузки / сохранения l1d: [ C(L1D ) ] - [ C(OP_READ) ] / [ C(OP_WRITE) ] - [ C(RESULT_MISS) ] поля эта странная структура данных (= 0 означает не сопоставлен, а skl_hw_cache_extra_regs L525 имеет дополнительные настройки umask для событий): 

static ... const... skl_hw_cache_event_ids ... =
{
 [ C(L1D ) ] = {
    [ C(OP_READ) ] = {
        [ C(RESULT_ACCESS) ] = 0x81d0,  /* MEM_INST_RETIRED.ALL_LOADS */
        [ C(RESULT_MISS)   ] = 0x151,   /* L1D.REPLACEMENT */
    },
    [ C(OP_WRITE) ] = {
        [ C(RESULT_ACCESS) ] = 0x82d0,  /* MEM_INST_RETIRED.ALL_STORES */
        [ C(RESULT_MISS)   ] = 0x0,
    }, ...
 },

Итак, для SkyLake L1d промахи определены для нагрузок (op_read) как и не определено для магазинов (op_write). И доступ к L1d определен для обеих операций.

Эти общие c события, вероятно, были созданы долгое время go, когда оборудование имело какое-то событие PMU для их реализации. Например, PMU Core 2 имеет отображение для этих событий: arch/x86/events/intel/core.c строка 1254 core2_hw_cache_event_ids const - промах чтения l1d равен L1D_CACHE_LD.I_STATE, промах записи l1d - L1D_CACHE_ST.I_STATE. Подсистема perf в ядре просто должна была сохранить много общих c имен событий, добавленных в старых версиях, для обеспечения совместимости.

Вы должны проверить вывод команды sudo perf list cache, чтобы выбрать поддерживаемые события для вашего процессора и его PMU . Эта команда (в последних версиях инструмента perf) будет выводить только сопоставленные общие имена c, а также будут печатать имена событий c, специфичные для оборудования. Вы также должны проверить руководства по Intel SDM , optimcounters и perfcounters , чтобы понять, как реализованы загрузка и сохранение и какие события PMU следует использовать для подсчета оборудования. events.

Хотя промахи в хранилище L1d недоступны на вашем процессоре, вам следует подумать о том, что такое промахи в хранилище и как они реализованы. Возможно, этот запрос будет передан на какой-то следующий уровень иерархии кеша / памяти, например, он станет доступом к хранилищу L2. Набор событий perf generi c уродлив (был введен в эпоху двухуровневого кеширования в Core2) и имеет только события кэша L1 и LL C (кеш последнего уровня). Не уверен, как LL C отображается в текущую эпоху общего L3, это L2 или L3 ( skylake ll c = L3 ). Но intel-specifici c events должно работать.

...