Можно ли использовать счетчики монитора производительности Intel для измерения пропускной способности памяти?

Можно ли использовать PMU Intel для измерения использования пропускной способности памяти для чтения/записи? Здесь "память" означает DRAM (т.е. Не попадает в любой уровень кэша).

Ответ 1

Да, это возможно, хотя это не обязательно так же просто, как программирование обычных счетчиков PMU.

Один из подходов - использование счетчиков программируемых контроллеров памяти, к которым осуществляется доступ через пространство PCI. Хорошим местом для начала является изучение собственной реализации Intel в pcm-memory на pcm-memory.cpp. В этом приложении показана пропускная способность каждого сокета или пропускной способности памяти, что подходит для некоторых целей. В частности, пропускная способность распределяется между всеми ядрами, поэтому на тихой машине вы можете предположить, что большая часть полосы пропускания связана с тестируемым процессом или если вы хотите контролировать на уровне сокета именно то, что вы хотите.

Другой альтернативой является использование тщательного программирования счетчиков "offcore repsonse". Они, насколько я знаю, относятся к трафику между L2 (последним ядром-частным кешем) и остальной частью системы. Вы можете фильтровать результат реакции offcore, поэтому вы можете использовать комбинацию различных событий "Пропустить L3" и умножать на размер строки кеша, чтобы получить пропускную способность чтения и записи. События довольно мелкие, поэтому вы можете еще больше разбить его тем, что вызвало доступ в первую очередь: выборка команд, запросы на запрос данных, предварительная выборка и т.д. И т.д.

Счетчики ответов offcore обычно отстают в поддержке такими инструментами, как perf и likwid, но, по крайней мере, последние версии имеют разумную поддержку даже для клиентских частей, таких как SKL.

Ответ 2

Да (ish), косвенно. Вы можете использовать связь между счетчиками (включая метку времени) для вывода других чисел. Например, если вы пробуете 1-секундный интервал и есть N промахов в кэше последнего уровня (3), вы можете быть уверены, что занимаете N * CacheLineSize байты в секунду.

Он становится немного более липким, чтобы точно относиться к программной активности, поскольку эти промахи могут отражать предварительную выборку процессора, активность прерывания и т.д.

Существует также morass of 'this cpu does not count (MMX, SSE, AVX,..), если этот бит конфигурации не находится в этом состоянии; таким образом, ваш собственный громоздкий....

Ответ 3

Средство мониторинга производительности отклика вне ядра может использоваться для подсчета всех исходящих от ядра запросов по IDI от конкретного ядра. Поле типа запроса может использоваться для подсчета определенных типов запросов, таких как чтение данных спроса. Однако, чтобы измерить пропускную способность памяти на ядро, количество запросов должно быть каким-то образом преобразовано в байты в секунду. Большинство запросов имеют размер строки кэша, то есть 64 байта. Размер других запросов может быть неизвестен и может добавить к пропускной способности памяти количество байтов, которое меньше или больше, чем размер строки кэша. Они включают в себя заблокированные запросы с разделением строк кэша, запросы WC, запросы UC и запросы ввода-вывода (но они не влияют на пропускную способность памяти) и запросы на забор, которые требуют завершения всех ожидающих MFENCE (MFENCE, SFENCE и сериализации инструкции).

Если вас интересует только кешируемая пропускная способность, вы можете посчитать количество кешируемых запросов и умножить их на 64 байта. Это может быть очень точным, если предположить, что кешируемый кэш-запрос с разделением строк редко К сожалению, обратные записи из L3 (или L4, если доступны) в память не могут быть подсчитаны средством отклика вне ядра на любой из текущих микроархитектур. Причина этого заключается в том, что эти обратные записи не основаны на ядре и обычно происходят как следствие пропуска конфликта в L3. Таким образом, запрос, который пропустил в L3 и вызвал обратную запись, может быть подсчитан, но средство ответа вне ядра не позволяет вам определить, вызвал ли какой-либо запрос к L3 (или L4) обратную запись или нет. Вот почему невозможно рассчитывать обратные записи в память "на ядро".

Кроме того, для событий отклика вне ядра требуется программируемый счетчик производительности, равный 0, 1, 2 или 3 (но не 4-7, когда отключена гипотеза).

Intel Xeon Broadwell поддерживает ряд функций Resource Director Technology (RDT). В частности, он поддерживает мониторинг пропускной способности памяти (MBM), который является единственным способом точного измерения пропускной способности памяти для каждого ядра в целом.

MBM имеет три преимущества по сравнению с оффкорным откликом:

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

Преимущество ответа offcore заключается в том, что он поддерживает поля типа запроса, типа поставщика и информацию отслеживания.

Linux поддерживает MBM, начиная с версии ядра 4.6. С 4.6 по 4.13 события MBM поддерживаются в perf с использованием следующих имен событий:

intel_cqm_llc/local_bytes - bytes sent through local socket memory controller
intel_cqm_llc/total_bytes - total L3 external bytes sent

К событиям также можно получить программный доступ.

Начиная с 4.14, реализация RDT в Linux значительно изменилась.

В моей системе BDW-E5 (с двумя сокетами), работающей под управлением ядра версии 4.16, я вижу количество байтов MBM, используя следующую последовательность команд:

// Mount the resctrl filesystem.
mount -t resctrl resctrl -o mba_MBps /sys/fs/resctrl

// Print the number of local bytes on the first socket.
cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_local_bytes

// Print the number of total bytes on the first socket.
cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_total_bytes

// Print the number of local bytes on the second socket.
cat /sys/fs/resctrl/mon_data/mon_L3_01/mbm_local_bytes

// Print the number of total bytes on the second socket.
cat /sys/fs/resctrl/mon_data/mon_L3_01/mbm_total_bytes

Насколько я понимаю, количество байтов считается с момента сброса системы.

Обратите внимание, что по умолчанию отслеживаемым ресурсом является весь сокет.

К сожалению, большинство функций RDT, включая MBM, оказалось неисправным на процессорах Skylake, которые его поддерживают. Согласно SKZ4 и SKX4:

Intel® Resource Director Technology (RDT) Мониторинг пропускной способности памяти (MBM) не учитывает кэшируемый трафик обратной записи в локальную память. Это приводит к функции RDT MBM при подсчете общей используемой полосы пропускания.

Вот почему он отключен по умолчанию в Linux при работе на Skylake-X и Skylake-SP (которые являются единственными процессорами Skylake, которые поддерживают MBM). Вы можете включить MBM, добавив следующий параметр rdt=mbmtotal,mbmlocal в командную строку ядра. В каком-то регистре нет флага для включения или отключения MBM или любой другой функции RDT. Вместо этого это отслеживается в некоторой структуре данных в ядре.

В микроархитектуре Intel Core 2 пропускная способность памяти на ядро может быть измерена с BUS_TRANS_MEM события BUS_TRANS_MEM как описано здесь.

Ответ 4

Я не уверен в Intel PMU, но я думаю, вы можете использовать Intel VTune Amplifier (https://software.intel.com/en-us/intel-vtune-amplifier-xe). У этого есть много инструментов для мониторинга производительности (память, процессорный кэш, процессор). Возможно, это сработает для вас.