На современных процессорах x86 (например, в семействе Sandybridge) страницы переходят по иерархии кеша (L1d / L2 / L3), так что да, есть очевидное преимущество в том, что разные каталоги страниц указывают на одно и то же поддерево для общей области виртуального адресное пространство. Или для некоторых AMD - через L2, пропуская L1d.
Что происходит после промаха TLB L2? содержит более подробную информацию об этом факте. этот обход страницы определенно выбирается через кеш, например Существуют счетчики производительности Broadwell для измерения попаданий.
(«MMU» является частью ядра ЦП; L1dTLB тесно связан с исполнительными модулями загрузки / хранения. Однако обходчик страниц - это довольно отдельная вещь, работающая параллельно с выполнением инструкций, но по-прежнему являющаяся частью ядра. и может запускаться умозрительно и т. д. Таким образом, он достаточно тесно связан для доступа к памяти через кеш L1d.)
PDE более высокого уровня (записи каталога страниц) можно кэшировать внутри аппаратного обеспечения обхода страниц. Раздел 3 в этот документ подтверждает, что Intel и AMD действительно делают это на практике, поэтому вам нужно очистить TLB в тех случаях, когда вы можете подумать, что вам не нужно .
Однако я не думаю, что вы обнаружите, что кэширование PDE происходит при изменении таблиц страниц верхнего уровня.
На x86 вы устанавливаете новую таблицу страниц с mov на CR3; который неявно очищает все кешированные переводы и внутреннее кэширование PDE обходчика страниц, как invlpg для одного виртуального адрес. (Или с ASID делает записи TLB из разных ASID недоступными для совпадений).
Основная проблема заключается в том, что внутренние кэши TLB и обходчика страниц несовместимы с кешами основной памяти / данных. Я думаю, что все ISA, которые выполняют обход страниц HW, вообще требуют ручной очистки TLB с семантикой вроде x86 для установки новой таблицы страниц. (Некоторые ISA, такие как MIPS, выполняют только программное управление TLB, вызывая специальный обработчик ошибок TLB ядра; ваш вопрос здесь не применяется.)
Так что да, они могут обнаруживать один и тот же физический адрес, но для здравомыслия вам также следует избегать использования устаревших кэшированных данных из хранилища на этот физический адрес.
Без аппаратной согласованности между хранилищами таблиц страниц и TLB / переходом по страницам этот кеш не может быть безопасным.
Тем не менее; некоторые процессоры x86 выходят за рамки того, что написано на бумаге, и обеспечивают ограниченную согласованность с хранилищами, но только защищают вас от спекулятивного обхода страниц для обратной совместимости с ОС, которые предполагали, что действительный, но еще не используемый PTE может быть изменен без invlpg. http://blog.stuffedcow.net/2015/08/pagewalk-coherence/ < / а>
Так что микроархитектуры нередко отслеживают магазины для обнаружения магазинов в определенных диапазонах; Вероятно, вы могли бы иметь хранилища, отслеживающие диапазоны адресов рядом с местами, кэшируемыми внутренним перемещением страниц, эффективно обеспечивая согласованность для внутренних кешей обходчика страниц.
Современный x86 действительно на практике обнаруживает самомодифицирующийся код с помощью отслеживания хранилищ рядом с любыми инструкциями в полете. Наблюдение за загрузкой устаревших инструкций на x86 с самим собой -Модификация кода. В этом случае слежение за отслеживанием обрабатывается путем сброса всего внутреннего состояния обратно в состояние вывода из эксплуатации.
Таким образом, вполне вероятно, что вы могли теоретически разработать ЦП с эффективным механизмом, позволяющим прозрачно использовать это преимущество, но он имеет существенное стоимость (отслеживание каждого магазина с помощью CAM для проверки совпадений в адресах, кэшированных в обходчике страниц) с очень низкой выгодой. Если я чего-то не упускаю, я не думаю, что есть более простой способ сделать это, поэтому я готов поспорить, что ни один настоящий дизайн на самом деле этого не делает.
Трудно представить себе вне x86; почти все остальное использует подход «слабее» / «меньше гарантий» и будет только отслеживать буфер хранилища (для пересылки хранилища). Модули CAM (content-addressable-memory = аппаратная хеш-таблица) потребляют много энергии, и обработка особого случая попадания усложнила бы конвейер. Особенно это касается конвейера OoO exec, где у хранилища PTE может быть не готовый адрес хранилища до тех пор, пока загрузка не захочет использовать эту запись TLB. Внедрение большего количества ядерных боеголовок - это плохо.
Польза от этого будет крошечной
После первого обхода страницы извлекает данные из кеша L1d (или дальше, если в L1d не было жарко), затем обычный кеш-обходчик механизмы могут действовать нормально.
Таким образом, дальнейшие обходы соседних страниц до следующего переключения контекста могут выиграть от внутренних кешей обходчика страниц. Это имеет преимущества, и это то, что делает некоторые настоящие HW (по крайней мере, некоторые x86; IDK для других).
Все приведенные выше аргументы о том, почему для этого потребуется отслеживание согласованных таблиц страниц, связаны с тем, чтобы внутренние кеши обходчика страниц оставались активными при переключении контекста.
L1d может легко это сделать; Кеши VIPT, которые ведут себя как PIPT (без псевдонимов), просто кешируют на основе физического адреса и не требуют сброса при переключении контекста.
Если вы переключаете контекст очень часто, ASID позволяет должным образом кэшировать записи TLB. Если вы по-прежнему получаете много промахов TLB, в худшем случае они должны получать через кеш полностью сверху. Это действительно неплохо, и не стоит тратить на это много транзисторов и энергопотребление.
Я рассматриваю только ОС на «голом железе», а не аппаратную виртуализацию с вложенными таблицами страниц. (Гипервизор виртуализирует таблицы страниц гостевой ОС). Я думаю, что все те же аргументы в основном применимы. Прогулка по страницам все еще определенно проходит через кеш.
person
Peter Cordes
schedule
03.12.2019
