Путаница в методах адресации кеша
Я читал о четырех способах обращения к кешу:
- Физически проиндексированный, физически помеченный (PIPT)
- Физически индексированный виртуально помеченный (PIVT)
- Фактически индексируется физически помечены (VIPT)
- Фактически проиндексированный Фактически маркированный (VIVT)
Какой из следующих кэшей будет страдать от проблем с синонимами и омонимами? Я знаю, что VIVT пострадает от этих проблем, а PIPT - нет. Но как насчет PIVT и VIPT?
1 ответ
Поскольку синонимы возникают, когда разные виртуальные адреса отображаются на один и тот же физический адрес (где нужно избежать ложных пропусков), в кеше VIPT синонимы могут быть (виртуально) проиндексированы для разных наборов кеша (в этом случае возможна несогласованность данных, например, посредством запись в синоним в одном наборе с последующим считыванием синонима [тот же физический адрес, другой виртуальный адрес] в другом наборе), в то время как в кеше PIVT синонимы всегда отображаются в один и тот же набор, но различие в части тега виртуального адрес может привести к отсутствию указания.
(Кэш PIVT с прямым отображением, который выполняет обратную запись потерпевшего блока до того, как пропущены службы, позволит избежать проблемы синонимов, поскольку фактическая доступная память [физический адрес] обязательно приведет к вытеснению любого синонима, поскольку индекс физического адреса будет то же самое, и в этом индексе есть только один блок. Прямой сопоставленный кэш PIVT с прямой записью будет вести себя аналогично по тем же причинам: самые последние значения данных будут в резервном хранилище [L2 или память]. Это предполагает, что любая запись буфер или кэш L2 физически помечены. Если резервное хранилище не обновляется до того, как пропущено обслуживание, то ложное промах [виртуальный адрес, не соответствующий тегу, но имеющий тот же физический адрес] может считывать устаревшие данные из резервного хранилища.)
(Обратите внимание, что PIVT обычно имеет смысл, только если виртуальный индекс совпадает с физическим индексом, т. Е. Когда используются виртуальные биты в пределах смещения страницы. Если кто-то уже знает полный физический адрес достаточно рано, чтобы индексировать кэш, то для этого нет особых причин. не использовать физический адрес для тегов.)
Использование сквозной записи не устранит проблему с синонимами, если синонимы могут отображаться в разные блоки в кэше. Если какие-либо биты индекса могут отличаться (с помощью виртуальной индексации) или предусмотрено более одного пути, то устаревшее значение может остаться в этом альтернативном месте и не может быть найдено, когда кэш проверяется с другим виртуальным адресом. Последовательность чтения A, записи B, чтения A (где A и B являются синонимами) может иметь второе чтение A, не видя результата записи B, когда второе чтение A является попаданием в кэш. (Даже с прямым отображением кэша сквозной записи любой буфер записи должен быть физически помечен [физическая индексация не является проблемой, поскольку буферы записи относительно малы].)
Хотя вероятность одновременного присутствия двух синонимов в кеше L1 с записью в один с последующим чтением другого может быть крайне низкой, все еще существует вероятность, что такие случаи будут обрабатываться правильно.
Поскольку омонимы возникают, когда один и тот же виртуальный адрес отображается на разные физические адреса (где нужно избежать ложных попаданий), в омонимах кеша VIPT будет отображаться один и тот же набор кешей, но теги будут другими (поэтому ложных совпадений нет) в то время как в кэше PIVT омонимы могут отображаться в один и тот же набор (если физические биты индексации совпадают) и ложно совпадать в виртуальных тегах.
Таким образом, маловероятный дизайн PIVT подвержен проблемам синонимов и омонимов, а дизайн VIPT подвержен только проблемам синонимов. Проект VIVT имеет все проблемы нереалистичного PIVT и более (даже специальный случай с прямым отображением не будет работать, поскольку синонимы могут отображаться в разные блоки, когда биты виртуального адреса, используемые для индексации, отличаются).
(При наличии нескольких ядер / процессоров согласованность обычно обрабатывается физическими адресами. Хотя можно было бы предоставить аналог TLB, который преобразует физические адреса в виртуальные адреса [это мог сделать по крайней мере один процессор PA-RISC], исключение из этот кэш трансляций приведет к тому, что любые блоки кеша, помеченные этим виртуальным адресом, будут выселены, что похоже на выселение, вызванное исчерпанием ASID.
Появления синонимов и омонимов
Записываемые синонимы, вероятно, вообще не распространены, но один из способов, которым они могут возникнуть, - это если файл отображен в памяти несколькими процессами. Очевидно, что если один процесс уже сопоставил (например, для динамической памяти) диапазон адресов, используемый другим процессом для сопоставления файла, то этот процесс не может сопоставить файл с тем же диапазоном виртуальных адресов, который использует другой процесс.
Синонимы только для чтения могут быть более распространенными. Некоторые операционные системы используют одну заполненную нулями страницу в системе и отображают множество виртуальных страниц на одну и ту же физическую нулевую страницу (используя копирование при записи, когда программа пытается выполнить запись на эту страницу). Если для каждого процесса применяется рандомизация макета адресного пространства (функция безопасности), разные процессы могут использовать разные виртуальные адреса для одних и тех же физических страниц кода / текста.
Возможно, наиболее распространенная форма омонимов связана с наличием нескольких адресных пространств. В обычных ОС каждому процессу предоставляется свое собственное адресное пространство (хотя ОС обычно резервирует часть этого адресного пространства для себя и использует одну и ту же карту для этого раздела в разных процессах). Этот тип омонима можно сделать менее проблематичным, добавив идентификатор виртуального адреса в адресное пространство. Таким образом, специальная обработка таких омонимов необходима, только когда ASID повторно используется для определенного виртуально тегированного кэша. (ASID уменьшают частоту специального управления кэшем, чтобы избежать проблем с омонимами, но они не устраняют проблему в целом. Однако даже снижение частоты может сделать программное обеспечение менее сложным за счет снижения требований к производительности; высокооптимизированный код часто бывает сложнее производить и сложнее в обслуживании.)
Другая форма омонима - когда страница выгружается, а затем возвращается в память по другому адресу. Если ввод / вывод выполняется из памяти (а не кеша, как в некоторых процессорах), то ОС должна по крайней мере записать обратно любое содержимое кеша, поэтому очистка соответствующего содержимого не является проблемой. В то время как вероятность того, что страница будет иметь некоторое содержимое в кеше (особенно в кеше L1, где использование виртуальных адресов является наиболее привлекательным из-за преимущества задержки), когда ОС считает ее хорошим кандидатом на удаление на диск, мала, и вероятность того, что любой такой контент будет оставаться в кэше до тех пор, пока страница не будет перенесена обратно в память, будет мало, даже произведение этих невероятностей не равно нулю.
В любом случае может быть желательно не требовать специальной обработки таких случаев, даже если разработчик оборудования не может придумать какое-либо стоящее использование для синонимов и омонимов.
В ОС с единым адресным пространством омонимы невозможны, поскольку все процессы используют одинаковое сопоставление виртуальных адресов с физическими адресами, а если разрешены синонимы, они предназначены только для чтения. В этих условиях кеши VIVT могут использоваться без проблем с омонимами и синонимами. (SASOS могут упростить межпроцессное взаимодействие. Однако UNIX-подобные ОС и некоторые другие ОС предназначены для нескольких адресных пространств.)
В качестве примечания, синонимы только для чтения памяти не вносят проблему корректности (просто потенциально тратят пропускную способность из-за ложных пропусков и емкость кеша из-за дублированного кеширования той же физической памяти). Это делает VIVT менее непривлекательным для кэшей инструкций. (x86 несколько необычен, когда требуется, чтобы кэши команд были когерентными, хотя предоставление когерентных кэшей команд может упростить некоторые программы.)
Кроме того, проблемы с синонимами в кэшах VIPT могут быть обработаны с использованием начального виртуального индекса в качестве формы прогнозирования пути (проверка альтернативных наборов при промахе - это было сделано с помощью двухстороннего кэша AMD Athlon 64 КиБ со страницами объемом 4 КиБ). - или использовать физически индексируемый кэш L2 с тегами с избыточным количеством битов виртуального адреса, используемого для индексации L1, делая недействительным блок в ранее кэшированном виртуальном индексе L1) или требуя, чтобы любые синонимы индексировали тот же набор блоков кеша (большинство просто путем раскраски страницы, где соответствующие биты физического адреса искусственно совпадают с битами виртуального адреса, используемыми для индексации).