Событие Intel PMU для события попадания в кэш L1

Я пытаюсь подсчитать количество попаданий в кеш на разных уровнях (L1, L2 и L3) кеша для программы на процессоре Intel Haswell.

Я написал программу для подсчета количества попаданий в кэш L2 и L3, отслеживая соответствующие события. Чтобы добиться этого, я проверил руководство по разработке программного обеспечения Intel x86 и использовал событие cache_all_request и событие cache_miss для кеша L2 и L3. Однако я не нашел событий для кеша L1. Может быть, я что-то пропустил?

Мои вопросы:

Какой номер события и значение UMASK следует использовать для подсчета событий попадания в кэш L1?

Пояснения*

1) Конечная цель, которую я хочу достичь, - это верхняя граница времени выполнения программы, когда все попадания в кеш программы становятся промахами в кеше. Если я могу подсчитать количество запросов на попадание в кеш, я могу рассматривать их как промахи в кеше и рассчитать увеличение времени выполнения;

2) Я проверил событие MEM_LOAD_UOPS_RETIRED.L1_ HIT в Intel SDM, оно говорит: «Удаленные загрузочные операции с кэш-памятью L1 в качестве источников данных». Я не уверен, что 1 мкп занимает 1 цикл. Есть ли упоминание о том, как перевести uops в циклы?

3) Лучше будет считать и нагрузки и магазины. (Хотя я могу мириться с тем, что не считаю запросы в хранилище.)

Спасибо большое за вашу помощь!


person Mike    schedule 01.03.2018    source источник
comment
Есть mem_load_retired.l1_hit. (Используйте обертку ocperf.py, чтобы вам не нужны были номера событий/umask или получить от него числа.) В качестве альтернативы используйте L1-dcache-loads - L1-dcache-load-misses. (Событий HW, которые подсчитывают сохранения, гораздо меньше, в основном потому, что ЦП не нужно их ждать, и они не фиксируются до тех пор, пока не отменяется инструкция сохранения. вы согласны с просто нагрузками?)   -  person Peter Cordes    schedule 01.03.2018
comment
@PeterCordes Большое спасибо за вашу помощь! Я изменил свой вопрос, чтобы ответить на ваш вопрос и уточнить мои вопросы. Надеюсь, вы могли бы направить меня. Спасибо!   -  person Mike    schedule 07.03.2018
comment
Как, черт возьми, вы планируете рассчитать увеличение времени выполнения? Вам нужно будет знать, какие нагрузки зависели от других нагрузок, чтобы выяснить, сколько промахов кеша может происходить одновременно (параллелизм памяти). И насколько хорошо неисправное ядро ​​может скрыть латентность кэш-промахов. Если есть независимая работа, не зависящая от нагрузки, она может быть выполнена и готова к удалению после завершения загрузки.   -  person Peter Cordes    schedule 07.03.2018
comment
Как говорит Питер, вы, вероятно, не можете сделать расчет, который вы предлагаете, каким-либо общим и разумным способом.   -  person BeeOnRope    schedule 08.03.2018
comment
@PeterCordes Да, я понял, что ты сказал. Я полностью согласен с тем, что точно рассчитать увеличенное время выполнения невозможно. Я намеревался установить верхнюю границу времени выполнения программы, если все ее запросы на попадание в кэш становятся промахами. Поэтому я просто предполагаю, что когда происходит дополнительный промах кеша, следующие инструкции не могут быть отменены до тех пор, пока не будет обслужен запрос промаха кеша. Это имеет больше смысла? Большое спасибо!   -  person Mike    schedule 08.03.2018
comment
@BeeOnRope Большое спасибо за ваш комментарий! Как насчет верхней границы увеличения времени выполнения? Это должно быть выполнимо, если я знаю дополнительный номер промаха кеша. Я согласен, что это может быть пессимистично, но это дает некоторые намеки на то, насколько медленно будет работать программа, если кеш отключен.   -  person Mike    schedule 08.03.2018
comment
Это не даст вам верхней границы. Пропускная способность Skylake составляет около 8 мопов за такт (или, может быть, даже 16 за такт, если оба потока имеют инструкции по удалению). Обратите внимание, что выполнение не по порядку + удаление по порядку, как правило, приводит к резкому выводу из эксплуатации, когда старая инструкция, наконец, завершает выполнение, и вывод из эксплуатации быстрее, чем узкое место проблемы, может привести к более раннему высвобождению ресурсов. В любом случае, чтобы получить что-то вроде верхней границы, нужно учитывать, какие цепочки зависимостей включают загруженные данные, потому что они не могут выполняться до тех пор, пока не будут завершены. Итак, задержка. ..   -  person Peter Cordes    schedule 08.03.2018
comment
По сути, вам нужно смоделировать всю вышедшую из строя технику. Для верхней границы вы могли бы смоделировать, как если бы это была машина в порядке, которая не может начать выполнение более поздней инструкции до тех пор, пока не завершится загрузка с промахом кеша, но это будет чрезвычайно свободная верхняя граница, вплоть до бесполезности . Вся эта идея в любом случае звучит очень нереалистично, потому что сохранение/перезагрузка в стек очень распространено и на практике не промахнется. И Store-Forwarding по-прежнему работает, даже если строки нет в кеше L1D.   -  person Peter Cordes    schedule 08.03.2018
comment
Есть ли какая-либо информация о том, как преобразовать uops в циклы? См. agner.org/optimize и другие ссылки на производительность в stackoverflow.com/tags/x86/info, где можно найти дополнительные сведения о микроархитектурах современных процессоры x86. Это не просто; нельзя игнорировать окружающий код и выполнение не по порядку. ROB Skylake составляет 224 мкп, а планировщик — 97 мкп. Таким образом, у него может быть 97 мопов, ожидающих ввода/исполнения ресурсов одновременно.   -  person Peter Cordes    schedule 08.03.2018
comment
@Mike - вы можете сделать что-то вроде умножения количества гипотетических дополнительных промахов (если все попадания были промахами) на задержку для DRAM (обычно от 50 до 100 нс на современном оборудовании) для какой-то верхней границы. Я даже не уверен, что это строгая верхняя граница (поскольку из-за эффектов планирования длительные промахи могут уменьшить параллелизм, а также задержку), но я подозреваю, что это верхняя граница для большинства реальных мировой код. Проблема в том, что эта верхняя граница ужасно расплывчата: я подозреваю, что большая часть кода могла бы работать на порядок лучше (например, см. комментарии Питера).   -  person BeeOnRope    schedule 09.03.2018
comment
Возможно, если бы вы объяснили свою мотивацию или вариант использования этого расчетного значения, можно было бы дать несколько лучших советов.   -  person BeeOnRope    schedule 09.03.2018