L1-dcache-misses - это доля всех загрузок , пропущенных в кеше L1d.
L2-пропусков - это доля запросов, которые вообще попадают в L2 (пропущено в L1) и затем пропустите в L2. Аналогично для L3.
Удар L1d не является частью общего доступа L2. (что имеет смысл, потому что L2 даже не видит его).
Это довольно нормально для рабочей нагрузки с хорошей локализацией по небольшому рабочему набору, но пропуски доступа, которые пропускаются в L1d, имеют плохую пространственно-временную локализацию и имеют тенденцию пропадать и во внешних кешах.
L1d отфильтровывает все «легкие» доступы с очень высокой локальностью, в результате чего L2 и L3 имеют дело только с «более сложными» доступами. Вы можете сказать, что L1d существует, чтобы обеспечить отличную задержку (и пропускную способность) для самого маленького горячего рабочего набора, в то время как L2 пытается отлавливать вещи, которые проваливаются в трещины. Тогда L3 видит только «самые сложные» части вашего шаблона доступа.
Кроме того, если вы используете процессор Intel, учтите, что perf не просто использует mem_load_retired.l1_miss события и скоро; он пытается посчитать множественные пропуски в одну и ту же линию L1d как одну промах с помощью события L1D.REPLACEMENT. LL C -нагрузки и пропуски используют события OFFCORE_RESPONSE, а не mem_load_retired.l3_hit / miss. См. Как Linux perf вычисляет ссылки на кэш и события отсутствия кеша
(две загрузки в одну и ту же строку кэша, которые еще не готовы, будут использовать одну и ту же LFB для отслеживания входящая линия, так что этот учет имеет смысл. Также, если мы заботимся о линиях, которых коснулись / пропустили вместо отдельных нагрузок. Но L1-dcache-loads использует MEM_INST_RETIRED.ALL_LOADS, который учитывает каждую нагрузку. Таким образом, даже сообщенный перфом коэффициент попадания L1 не является действительно частота обращений к загрузке L1d для каждой инструкции. Она будет выше для любой программы с отсутствием L1d в пространственной локальности.)