Как конвертация VIPT в PIPT работает при выселении L1->L2
Этот сценарий пришёл мне в голову и кажется немного базовым, но я спрошу.
Таким образом, в L1 есть виртуальный индекс и физический тег, но набор заполняется, поэтому он выселяется. Как контроллер L1 получает полный физический адрес из виртуального индекса и физического тега в L1, чтобы линия могла быть вставлена в L2? Я полагаю, что он может искать комбинацию в TLB, но она кажется медленной, а также может вообще отсутствовать в TLB. Возможно, полный физический адрес из исходного перевода TLB хранится в L1 рядом со строкой кэша?
Это также открывает более широкий вопрос о том, как PMH делает недействительной запись L1, когда она записывает доступные биты в PTE и PDE и так далее. Насколько я понимаю, он взаимодействует с кэш-памятью L2 напрямую для физических адресов, но когда он записывает обращенные и измененные биты, а также отправляет RFO, если это необходимо, он должен отражать изменение в копии в L1, если есть один означает, что он должен знать виртуальный индекс физического адреса. В этом случае, если полный физический адрес также был сохранен в L1, то это дает возможность L2 также иметь возможность его индексировать.
1 ответ
Да, внешние кэши (почти?) Всегда PIPT, а сама память, очевидно, нуждается в физическом адресе. Поэтому вам нужен физический адрес строки, когда вы отправляете ее в иерархию памяти.
В процессорах Intel кэш-память VIPT L1 имеет все биты индекса из части адреса со смещением внутри страницы, поэтому virt=phys, что позволяет избежать проблем с наложением имен. Это в основном PIPT, но он по-прежнему может извлекать данные / теги из набора параллельно с поиском TLB битов pagenumber, чтобы создать вход для компаратора тегов.
Полный физический адрес известен только из L1d index + tag, опять же, потому что он ведет себя как PIPT для всего, кроме задержки загрузки.
В общем случае с практически индексированными кешами, где некоторые биты индекса поступают из номера страницы, это хороший вопрос. Такие системы существуют, и ОС часто использует раскраску страниц, чтобы избежать псевдонимов. (Поэтому им не нужно очищать кэш при переключении контекста.)
Фактически индексируемый физически помеченный кэш Синоним имеет диаграмму для одного такого VIPT L1d:физический тег расширяется на несколько битов, чтобы полностью доходить до смещения страницы, перекрывая верхний бит индекса.
Хорошее наблюдение, что кэш с обратной записью должен иметь возможность удалять грязные строки еще долго после того, как была выполнена проверка TLB для хранилища. В отличие от загрузки, вы все равно не получите результат TLB, если вы не сохранили его где-нибудь.
Наличие тега, включающего все биты физического адреса выше смещения страницы (даже если оно перекрывает некоторые биты индекса), решает эту проблему.
Другим решением может быть сквозной кэш, так что у вас всегда есть физический адрес из TLB для отправки с данными, даже если он не восстанавливаемый из тега + индекса кеша. Или для кэшей только для чтения, например, кешей инструкций, виртуальность не является проблемой.
Но я не думаю, что проверка TLB при выселении могла бы решить проблему для случая неперекрывающегося тега: у вас больше нет полного виртуального адреса, только младшие биты вашего номера страницы являются виртуальными (из индекса) Остальные физические (из тега). Так что это недопустимый вклад в TLB.
Таким образом, помимо неэффективности, есть также не менее важная проблема, которая не будет работать вообще.:P Может быть, есть какой-то трюк, которого я не знаю, или что-то, чего я пропускаю, но я не думаю, что даже специальный TLB, индексированный обоими способами (phys->virt и virt->phys), мог бы работать, потому что множественные отображения одна и та же физическая страница разрешена.
Я думаю, что реальные процессоры, которые использовали VIVT-кеши, обычно использовали их для сквозной записи. Я недостаточно хорошо знаю историю, чтобы сказать наверняка или привести какие-либо примеры. Я не понимаю, как они могут выполнять обратную запись, если они не хранят два тега (физический и виртуальный) для каждой строки.
Я думаю, что ранние процессоры RISC часто имели 8k кешей прямого отображения.
Но классический 5-ступенчатый MIPS R2000 первого поколения (использующий внешнюю SRAM для своего L1), по-видимому, имел кэш обратной записи PIPT, если диаграмма на этих слайдах, помеченная MIPS R2000, верна, показывая 14-битный индекс кэша, принимающий некоторые биты из номер физической страницы результата TLB. Но он по-прежнему работает с задержкой в 2 цикла для нагрузок (1 для генерации адреса на этапе EX, 1 для доступа к кэшу на этапе MEM).
В те дни тактовые частоты были намного ниже, а кэши +TLB стали больше. Я предполагаю, что тогда 32-разрядный двоичный сумматор в ALU имел сравнимую задержку с доступом к кэш-памяти TLB +, возможно, не использовал в качестве агрессивных конструкций для переноса или переноса.
Таблица данных MIPS 4300i(вариант MIPS 4200, используемый в Nintendo 64) показывает, что происходит где / когда в 5-ступенчатом конвейере, когда некоторые вещи происходят на восходящем или падающем фронте тактовой частоты, позволяя ему делить некоторые вещи пополам часы в пределах сцены. (например, переадресация может работать с первой половины одной стадии до второй половины другой, например, для цели перехода -> выборка инструкций, все еще без необходимости дополнительной фиксации между полуэтапами.)
В любом случае, он показывает расчет DVA (виртуальный адрес данных), происходящий в EX: это регистр + imm16 из lw $t0, 1234($t1), Затем DTLB и DCR (чтение из кэша данных) происходят параллельно в первой половине этапа Data Cache. (Так что это VIPT). DTC (проверка меток данных) и LA (выравнивание нагрузки, например, сдвиг для LWL / LWR или для LBU для извлечения байта из извлеченного слова) происходят параллельно во 2-й половине этапа.
Таким образом, я до сих пор не нашел подтверждения одноконтурного (после вычисления адреса) PIPT MIPS. Но это определенное подтверждение того, что VIP-цикл с одним циклом был чем-то особенным. Из Википедии мы знаем, что ее D-кэш имел обратную запись с прямым отображением 8 КБ.