Подсчет количества выделений в очереди на запись - неожиданный низкий результат в памяти NV - PullRequest
Новая
       80

Подсчет количества выделений в очереди на запись - неожиданный низкий результат в памяти NV

4 голосов
/ 24 марта 2020

Я пытаюсь использовать некоторые из неосновных аппаратных счетчиков, например: skx_unc_imc0-5::UNC_M_WPQ_INSERTS. Предполагается подсчитать количество выделений в очереди на запись. Машина имеет 2 процессора Intel Xeon Gold 5218 с архитектурой каскадного озера, с 2 контроллерами памяти на процессор. linux версия 5.4.0-3-amd64. У меня есть следующее простое l oop, и я читаю этот счетчик для него. Элементы массива имеют размер 64 байта, равный строке кэша. 

for(int i=0; i < 1000000; i++){
        array[i].value=2;
}

Для этого l oop, когда я сопоставляю память с узлом DRAM NUMA, в результате счетчик выдает около 150 000, что, возможно, составляет смысл: в общей сложности 6 каналов для 2 контроллеров памяти перед этим узлом NUMA, которые используют модули DIMM DRAM в режиме чередования. Тогда для каждого канала есть один отдельный WPQ, я полагаю, поэтому skx_unc_imc0 получает 1/6 от всех магазинов. Есть счетчики skx_unc_imc0-5, которые я получил с papi_native_avail, предположительно каждый для разных каналов.

Неожиданный результат заключается в том, что вместо сопоставления с узлом DRAM NUMA я сопоставляю программу с энергонезависимой памятью, которая представляется как отдельный узел NUMA в том же сокете. Для каждого сокета имеется 6 модулей NVM DIMM, которые создают один чередующийся регион. Таким образом, при записи в NVM должно использоваться 6 разных каналов, а перед каждым - один и тот же WPQ, который должен получить 1/6 вставок записи.

Но UNC_M_WPQ_INSERTS возвращает только около 1000 в результате в памяти NV. Я не понимаю, почему; Я ожидал, что он даст примерно 150 000 записей в WPQ.

Я что-то неправильно понимаю? Или есть два разных WPQ на канал в зависимости от того, идет ли запись в DRAM или NVM? Или что еще может быть объяснение?

1 Ответ

2 голосов
/ 26 марта 2020

Оказывается, что UNC_M_WPQ_INSERTS подсчитывает количество выделений в очереди на запись, только для записи в DRAM. Корпорация Intel добавила соответствующий счетчик аппаратного обеспечения для постоянной памяти: UNC_M_PMM_WPQ_INSERTS, который подсчитывает количество запросов на запись, выделенных в очереди отложенной записи PMM для постоянной памяти Intel® Optane ™ D C.

Однако такое собственное событие не отображается в papi_native_avail, что означает, что пока нельзя отслеживать с помощью PAPI. В linux версии 5.4 некоторые счетчики PMM можно непосредственно найти в perf list uncore, например unc_m_pmm_bandwidth.write - Intel Optane D C запись пропускной способности постоянной памяти (МБ / с c), полученная из unc_m_pmm_wpq_inserts , ед .: uncore_im c. Это подразумевает, что, хотя UNC_M_PMM_WPQ_INSERTS не указан непосредственно в perf list как событие, оно должно существовать на машине.

Как описано здесь Код события для этого счетчика: 0xE7, поэтому его можно использовать с perf в качестве дескриптора необработанного аппаратного события следующим образом: perf stat -e uncore_imc/event=0xe7/. Однако, похоже, что он не поддерживает модификаторы событий для указания подсчета пространства пользователя с помощью perf. Затем, после закрепления потока в том же сокете, что и узел NUMA NVM, для программы, которая в основном выполняет только l oop, описанную в вопросе, результат типа perf имеет смысл: 

Performance counter stats for 'system wide':  1,035,380    uncore_imc/event=0xe7/

Пока что это лучшее предположение.

...