Какая адресация используется в процессорах x86/x86_64 для кэширования в L1, L2 и L3 (LLC) - физическом или виртуальном (с использованием PT/PTE и TLB) и как-то влияет на это PAT(page attribute table)?Физическая или виртуальная адресация используется в процессорах x86/x86_64 для кэширования в L1, L2 и L3?
И есть ли разница между драйверами (пространство ядра) и приложениями (пользовательское пространство) в этом случае?
Ответ на ваш вопрос - это зависит. Это строго решение для проектирования процессоров, которое уравновешивает компромисс между производительностью и сложностью.
Возьмите, например, новейшие процессоры Intel Core - они физически помечены и фактически проиндексированы (по крайней мере, согласно http://www.realworldtech.com/sandy-bridge/7/). Это означает, что кэши могут выполнять только поиск в чистом физическом адресном пространстве, чтобы определить, есть ли строка или нет. Однако, поскольку L1 32k, 8-way ассоциативный, это означает, что он использует 64 набора, поэтому вам нужно только биты адреса 6-11, чтобы найти правильный набор. Как бы то ни было, виртуальные и физические адреса в этом диапазоне одинаковы, поэтому вы можете искать DTLB параллельно с чтением набора кеша - известный трюк (см. - http://en.wikipedia.org/wiki/CPU_cache для хорошего объяснения).
Теоретически можно создать кеш с виртуальным индексом + виртуальным тегом, который устранит необходимость прохождения преобразования адресов (поиск TLB, а также проходы страницы в случае пропусков TLB). Однако это может вызвать множество проблем, особенно с использованием псевдонимов памяти - случай, когда два виртуальных адреса сопоставляются с одним и тем же физическим.
Скажем, у ядра 1 есть виртуальный адр. Кэши в таком полностью виртуальном кэше (он сопоставляется с физическим аддиром C, но мы еще не выполнили эту проверку). core2 записывает в виртуальный addr B, которые сопоставляются с одним и тем же физическим addr C - это означает, что нам нужен какой-то механизм (обычно это «snoop», термин, придуманный Джим Гудман), который идет и делает недействительной эту строку в core1, управляя слиянием данных и управлением согласованностью если нужно. Тем не менее, core1 не может ответить на этот snoop, поскольку он не знает о виртуальном добавлении B и не сохраняет физический адр C в виртуальном кэше. Таким образом, вы можете видеть, что у нас есть проблема, хотя это в основном относится к строгим системам x86, другие архитектуры могут быть более слабыми и позволяют более простое управление такими кэшами.
Что касается других вопросов - нет реальной связи с PAT, о которой я могу думать, кеш уже разработан и не может меняться для разных типов памяти. Тот же ответ на другой вопрос - HW в основном ниже различий между режимом пользователя/ядра (за исключением механизмов, которые он обеспечивает для проверки безопасности, в основном различных колец).
Большое спасибо! И, на ваш взгляд, есть ли какая-либо польза от знания механизма на x86, и могу ли я как разработчик это знать, могу ли я как-то оптимизировать производительность своей программы? – Alex
Абсолютно, разработчик SW, который не знает, на какой HW он работает, будет плохо работать над его оптимизацией (если необходимо) или отлаживать его (если необходимо :). Тип адреса отображения кеша на самом деле немного низкий, хотя он открывает штрих к некоторым важным оптимизациям, таким как внутренняя среда предварительной выборки и дизайн с поддержкой кэширования). См. Этот отличный пост для примеров - http://stackoverflow.com/questions/16699247/what-is-cache-friendly-code. Также есть вопрос об исполнении вне порядка, который может дать некоторые подсказки, и, конечно же, разнообразие оптимизаций компилятора (но не HW, но важно тоже) – Leeor
Я имею в виду - пользуюсь знаниями о том, что в x86: «они есть физически помечен и фактически индексирован » – Alex
Вы не можете обращаться к кешу. Вы можете обращаться только к памяти. Кэш обрабатывается ЦП в частном порядке. –
@Kerrek SB Да, я знаю, но использует ли процессорный кэш TLB и все накладные расходы виртуальной адресации или нет? – Alex