Можно ли использовать счетчики монитора производительности Intel для измерения пропускной способности памяти?
Можно ли использовать Intel PMU для измерения пропускной способности памяти для чтения / записи на ядро? Здесь "память" означает DRAM (то есть не попадает ни на один уровень кэша).
5 ответов
Да, это возможно, хотя это не обязательно так просто, как программирование обычных счетчиков PMU.
Одним из подходов является использование программируемых счетчиков контроллера памяти, доступ к которым осуществляется через пространство PCI. Хорошее место для начала - изучение собственной реализации Intel в pcm-memory в pcm-memory.cpp. Это приложение показывает пропускную способность для каждого сокета или контроллера памяти, что подходит для некоторых целей. В частности, полоса пропускания распределяется между всеми ядрами, поэтому на тихой машине можно предположить, что большая часть полосы пропускания связана с тестируемым процессом, или если вы хотите отслеживать на уровне сокетов, это именно то, что вам нужно.
Другой альтернативой является тщательное программирование счетчиков "offcore repsonse". Насколько я знаю, они относятся к трафику между L2 (последний частный кеш-кеш) и остальной частью системы. Вы можете отфильтровать по результату отклика offcore, так что вы можете использовать комбинацию различных событий "L3 miss" и умножаться на размер строки кэша, чтобы получить пропускную способность для чтения и записи. События достаточно детализированы, так что вы можете далее разбить их на то, что вызвало доступ в первую очередь: выбор инструкций, запросы запроса данных, предварительная выборка и т. Д. И т. Д. И т. Д.
Счетчики ответа offcore обычно отстают в поддержке такими инструментами, как perf а также likwid но, по крайней мере, последние версии, кажется, имеют разумную поддержку, даже для клиентских частей, таких как SKL.
Да (иш), косвенно. Вы можете использовать отношения между счетчиками (включая отметку времени), чтобы вывести другие числа. Например, если вы выберете 1-секундный интервал, и при этом будет пропущено N кэшей последнего уровня (3), вы можете быть уверены, что занимает N*CacheLineSize байт в секунду.
Становится немного сложнее связать его с программной активностью, поскольку эти пропуски могут отражать предварительную выборку процессора, работу с прерываниями и т. Д.
Существует также ощущение, что "этот процессор не считается (MMX, SSE, AVX, ..), если этот бит конфигурации не находится в этом состоянии"; таким образом, сворачивание собственного является громоздким....
Средство мониторинга производительности отклика вне ядра может использоваться для подсчета всех исходящих от ядра запросов по IDI от конкретного ядра. Поле типа запроса может использоваться для подсчета определенных типов запросов, таких как чтение данных спроса. Однако, чтобы измерить пропускную способность памяти на ядро, количество запросов должно быть каким-то образом преобразовано в байты в секунду. Большинство запросов имеют размер строки кэша, то есть 64 байта. Размер других запросов может быть неизвестен и может добавить к пропускной способности памяти количество байтов, которое меньше или больше, чем размер строки кэша. Они включают в себя заблокированные запросы с разделением строк кэша, запросы WC, запросы UC и запросы ввода-вывода (но они не влияют на пропускную способность памяти) и запросы на забор, которые требуют завершения всех ожидающих записей (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:\
На некоторых архитектурах с
perf вы можете получить доступ к счетчикам uncore-PMU контроллера памяти.
$ perf list
[...]
uncore_imc_0/cas_count_read/ [Kernel PMU event]
uncore_imc_0/cas_count_write/ [Kernel PMU event]
uncore_imc_0/clockticks/ [Kernel PMU event]
[...]
Потом:
$ perf -e "uncore_imc_0/cas_count_read/,uncore_imc_0/cas_count_write/" <program> <arguments>
сообщит количество байтов, передаваемых из основной памяти в кэш при операциях чтения и записи из контроллера памяти №0. Разделите это число на использованное время, и вы получите приблизительное значение средней используемой пропускной способности памяти.
Я не уверен насчет Intel PMU, но думаю, что вы можете использовать Intel VTune Amplifier ( https://software.intel.com/en-us/intel-vtune-amplifier-xe). У этого есть много инструментов для мониторинга производительности (память, кэш процессора, процессор). Может быть, это будет работать для вас.