Я выполняю некоторые измерения производительности кэша, и мне нужно убедиться, что в кэшах нет «полезных» данных до времени.
Предполагая, что кэш L3 равен 10 МБ, достаточно будет создать вектор размером 10M / 4 = 2 500 000 с плавающей запятой, выполнить итерацию по всему этому вектору, суммировать числа, и это очистит весь кэш любых данных, которые были в нем, до итерации вектор?
Да, этого должно быть достаточно для L3
кеш полезных данных.
Я провел аналогичные измерения и провел перекрестную проверку, используя счетчики кэша Intel, чтобы убедиться, что я получаю ожидаемое количество L3
тайник отсутствует во время моих тестов.
Если вы хотите быть абсолютно уверенным, вы также должны использовать счетчики. В частности, вы можете измерить ошибки кэша последнего уровня, используя Event select 2EH, Umask 41H
в большинстве архитектур Intel.
Увидеть Руководство Intel для деталей об этих счетчиках.
Это зависит от того, насколько безумным ты пытаешься получить свою гарантию.
Кэш-память третьего уровня x86_64 физически индексируется, и хотя линейный в виртуальном пространстве чанк 10 МБ почти наверняка будет физически смежным на слегка загруженной памяти, это не гарантируется.
Например, Sandy и Ivy Bridge имеют кэш-память третьего уровня в 2-мегабайтных слайсах с 16-полосной ассоциативностью набора (шаг 128 кБ), поэтому вы можете гарантировать физическое покрытие, выполнив MAP_HUGETLB
mmap()
звоните, предполагая стандартные 2-4MiB огромных страниц.
Кроме того, поскольку каждый срез (по крайней мере, на новом мосте Sandy / Ivy Bridge) подключен к другому ядру, и на каком срезе находится данный физический адрес, определяется хешем некоторых битов адреса низкого / среднего порядка, возможно, вам придется сделать массив немного больше, чем размер L3, чтобы противостоять незначительному неравномерному перекрытию.
На этом этапе очистка массива несколько раз линейно должна помочь.
Другой вариант — использовать инструкции по аннулированию выделенного кэша, которые предоставляют некоторые ISA. например, x86 имеет wbinvd
для этой цели (или clflush
для одной строки).
http://x86.renejeschke.de/html/file_module_x86_id_325.html
Одна из проблем заключается в том, что для этого требуются права доступа «0». Другое — то, что он не гарантирует, что очистка завершена до какой-либо точки сериализации, поэтому он не достаточно хорош, чтобы гарантировать энергонезависимость системы, но этого может быть достаточно для бенчмаркинга, если вы можете предотвратить последующее употребление WB. до вашей пропускной способности памяти.
Если вы можете преодолеть эти проблемы, в некоторых случаях это может быть лучшим решением, чем обход большой структуры данных только для того, чтобы убедиться, что кэш очищен. Некоторые процессоры могут решить избежать выборок кэширования, которые, по их мнению, не будут использоваться повторно в будущем (есть несколько статей об этих параметрах и, по крайней мере, некоторые утверждения, что они реализованы в реальных процессорах)