Методы адресации кэша Confusion

Я читал о четырех способах, которыми может быть адресован кеш:

  • Физически индексированная физическая метка (PIPT)

  • Физически индексированный объект с меткой (PIVT)

  • Фактически индексированный физически тегированный (VIPT)

  • Практически проиндексирован практически с меткой (VIVT)

Какой из следующих кешей пострадает от проблем синонима и омонима? Я знаю, что VIVT пострадает от этих проблем, и PIPT не будет. Но что насчет PIVT и VIPT?

Спасибо

Ответ 1

Поскольку синонимы возникают, когда разные виртуальные адреса сопоставляются с одним и тем же физическим адресом (где нужно избегать ложных промахов), в кешировании VIPT синонимы могут быть (фактически) индексированы на разные кэш-наборы (в этом случае возможна несогласованность данных, например, путем записи в синоним в одном наборе, за которым следует чтение синонима [тот же физический адрес, другой виртуальный адрес] в другом наборе), в то время как в синтаксисе кэша PIVT всегда сопоставляются с одним и тем же набором, но разница в части тега виртуального адреса может привести к пропущению.

(Кэш PIVT с прямым отображением, который выполняет обратную связь с жертвой блока до того, как пропустить службы, позволит избежать проблемы с синонимом, поскольку фактический доступ к памяти [физический адрес] обязательно приведет к выселению любого синонима, поскольку индекс физического адреса будет одним и тем же, и в этом индексе будет только один блок. Пишущий PIVT-кеш с прямой записью будет вести себя аналогичным образом по тем же причинам: самые последние значения данных будут в хранилище резервных копий [L2 или в памяти]. что любой буфер записи или L2-кеш физически помечен. Если хранилище резервных копий не обновляется до того, как пропустить сервис, то ложное промаха [виртуальный адрес, не соответствующий тегу, но имеющий тот же физический адрес], может считывать устаревшие данные из хранилища резервных копий.)

(Примечание. PIVT обычно имеет смысл только тогда, когда виртуальный индекс совпадает с физическим индексом, т.е. когда используются виртуальные биты в смещении страницы. Если вы уже знаете полный физический адрес достаточно рано, чтобы индексировать кеш, мало оснований не использовать физический адрес для тегов.)

Использование write-through не удаляет проблему синонима, пока синонимы могут отображаться в разных блоках в кеше. Если бы какие-либо индексные биты могли отличаться (с виртуальной индексацией) или более одного способа, то устаревшее значение могло оставаться в этом альтернативном месте и не обнаруживаться, когда кэш проверяется другим виртуальным адресом. Последовательность чтения A, запись B, чтение A (где A и B - синонимы) может иметь второе чтение A, не видят результат записи B, когда эта вторая прочитанная A является хитом кэша. (Даже с кэшем записи с прямым отображением любой буфер записи должен быть физически помечен (физическая индексация не является проблемой, поскольку буферы записи относительно малы).

Хотя вероятность одновременного присутствия двух синонимов в кэше L1 с записью в одну, за которой следует чтение другой, может быть крайне низкой, все еще есть ожидание, что такие случаи будут обрабатываться правильно.

Так как омонимы происходят, когда один и тот же виртуальный адрес сопоставляется с разными физическими адресами (где нужно избегать ложных ударов), в омонимах VIPT кеширования будет отображаться один и тот же набор кешей, но теги будут разными (поэтому нет ложные удары), в то время как в олинимах кеша PIVT может отображаться один и тот же набор (если совпадают индексирующие физические биты) и ложно совпадают в виртуальных тегах.

Таким образом, маловероятный дизайн PIVT подвержен синонимам и проблемам омонимии, а дизайн VIPT зависит только от проблем синонимов. Конструкция VIVT имеет все проблемы нереалистичного PIVT и более (даже специальный случай с прямым отображением не будет работать, поскольку синонимы могут отображаться на разные блоки, когда биты виртуальных адресов, используемые для индексирования, различны).

(С несколькими ядрами/процессорами когерентность обычно обрабатывается физическими адресами. Хотя можно было бы предоставить TLB-аналог, который преобразует физические адреса в виртуальные адреса [по крайней мере, один процессор PA-RISC мог бы это сделать] выселение из этого кэша переводов заставит любые блоки кэша, помеченные этим виртуальным адресом, быть выселенными, несколько похожими на выселения, вызванные истечением ASID.)

Возникновения синонимов и омонимов

Записываемые синонимы, вероятно, не являются общими в общем, но один из способов, которым они могут произойти, - это если файл является памятью, отображаемой несколькими процессами. Очевидно, что если один процесс уже отображен (например, для памяти кучи), диапазон адресов, используемый другим процессом для сопоставления файла, то этот один процесс не может сопоставить файл с тем же диапазоном виртуальных адресов, что и другой процесс.

Синонимы только для чтения могут быть более распространенными. Некоторые ОС используют одну нулевую заполненную страницу в системе и отображают множество виртуальных страниц на эту же физическую нулевую страницу (используя копию при записи, когда программа пытается записать на эту страницу). Если для каждого процесса применяется рандомизация компоновки адресного пространства (функция безопасности), разные процессы могут использовать разные виртуальные адреса для одних и тех же физических страниц кода/текста.

Возможно, наиболее распространенная форма омонимов связана с наличием нескольких адресных пространств. В обычных операционных системах каждому процессу предоставляется собственное адресное пространство (хотя ОС обычно резервирует часть этого адресного пространства для себя и использует одну и ту же карту для этого раздела в разных процессах). Этот тип омонима можно сделать менее проблематичным, добавив идентификатор адресного пространства в виртуальный адрес. Таким образом, специальная обработка таких омонимов необходима только тогда, когда ASID повторно используется для конкретного фактически помеченного кеша. (ASIDs уменьшают частоту использования специального кеша, чтобы избежать проблем с омонимами, но они не устраняют проблему в целом. Однако даже уменьшение частоты может сделать программное обеспечение менее сложным, снижая требования к производительности, а очень оптимизированный код часто является более сложным для производства и более сложного в обслуживании.)

Еще одна форма омонима - это когда страница выгружается и затем заменяется обратно на другой адрес. Если I/O выполняется из памяти (не кэшируется, как в некоторых процессорах), то ОС должна хотя бы переписывать содержимое кэша, поэтому очистка соответствующего содержимого является проблемой. Хотя вероятность того, что страница будет иметь некоторое содержимое в кеше (особенно кеш L1, где использование виртуальных адресов является наиболее привлекательной из-за латентного преимущества), когда ОС считает, что хороший кандидат на выселение на диск является низким и вероятность того, что любой такой контент будет оставаться в кеше до тех пор, пока страница не будет заменена обратно в память, будет низкой, даже продукт этих невероятностей не равен нулю.

В любом случае может потребоваться не требовать специальной обработки таких случаев, даже если разработчик аппаратного обеспечения не может придумать сколько-нибудь целесообразное использование для синонимов и омонимов.

С Одиночной Одиночной Осью Омонимизация невозможна, поскольку все процессы используют одно и то же сопоставление виртуальных адресов с физическими адресами, и если синонимы разрешены, они предназначены для постоянной памяти. В этих условиях кеши VIVT могут использоваться без омонимов и синонимов. (SASOS могут упростить межпроцессное взаимодействие. Однако UNIX-подобные ОС и некоторые другие ОС предназначены для нескольких адресных пространств.)


В качестве побочного примечания синонимы только для чтения памяти не представляют проблемы корректности (просто потенциально теряя пропускную способность от ложных промахов и емкости кэша от дублирования кэширования одной и той же физической памяти). Это делает VIVT менее непривлекательным для кэшей команд. (x86 несколько необычен в требовании кэширования кэшей кэша, хотя предоставление когерентных кэшей команд может упростить некоторое программное обеспечение.)

Кроме того, проблемы с синонимами в кешках VIPT можно обрабатывать с использованием начального виртуального индекса как формы прогнозирования пути (зондирование альтернативных наборов на пропуске - это было сделано AMD Athlon 64 KiB, 2-way cache с 4 страницы KiB - или с использованием физически проиндексированного кэша L2 с тегами, содержащего лишние виртуальные адресные биты, используемые для индексирования L1, недействительность блока в ранее кэшированном виртуальном индексе L1) или путем запроса каких-либо синонимов для индексации одного и того же набора кешей (наиболее просто путем раскраски страниц, где соответствующие физические биты адреса искусственно совпадают с битами виртуального адреса, используемыми для индексирования).