Кэшируются ли таблицы страниц?

На микропроцессоре с аппаратным управлением TLB (скажем, Intel x86-64), если происходит пропадание TLB, и процессор просматривает таблицу страниц, эти (не связанные с микросхемой) обращения к памяти проходят через иерархию кеша (L1, L2 и т. Д.). )?

Да, насколько я могу судить, на процессорах Intel x86-64, когда происходит пропадание TLB и процессор просматривает таблицу страниц, эти обращения к памяти вне кристалла проходят через иерархию кеша.

Я все еще немного размышляю над некоторыми деталями, и я надеюсь, что какой-то другой ответ заполнит их - разве нет руководства Intel или AMD, в котором описываются мучительные детали страницы? Мое понимание таково:

• Виртуальный адрес в некотором регистре адресов сначала передается быстрому TLB для преобразования в физический адрес - адрес в ПК передается в ITLB L1, адрес в любом другом регистре передается в DTLB L1. ,
• Если этот первый поиск пропущен, существует другой уровень более медленного, большего TLB. (Этот TLB L2 разделен на ITLB и DTLB также, или это унифицированный кэш TLB? Существуют ли другие уровни TLB - L3? L4?)
• Если поиск TLB полностью завершается неудачно, а обходчик VHPT x86 и x86-64 отключен, ЦП сообщает об ошибке пропуска TLB, которая перехватывается ядром ОС. Насколько я понимаю, практически все процессоры, отличные от x86, делают одно и то же - полностью обрабатывают ошибки TLB в программном обеспечении. Если включено, процессоры x86 и x86-64 имеют аппаратный обходчик таблиц VHPT, который обрабатывает следующие несколько шагов. (Есть ли у чипов x86 и x86-64 один бит, который полностью отключает VHPT, или есть много битов, которые могут включать VHPT для некоторых диапазонов адресов и отключать VHPT для других диапазонов адресов? Где эти биты расположены?)
• если поиск TLB полностью завершается неудачей, исходный (вероятно, в пользовательском режиме) виртуальный адрес V1 преобразуется в V2, виртуальный адрес PTE записи таблицы страниц, который содержит физический номер страницы для V1.
• Поскольку V2 снова является виртуальным адресом, ЦП проходит обычную трансляцию виртуального адреса, за исключением того, что пропускает L1 и переходит прямо к L2.
• Аппаратное обеспечение ищет виртуальный адрес V2 в TLB параллельно с извлечением этого PTE из (практически индексированного) кэша L2.
• Поскольку V2 не является адресом инструкции, он не проходит через кэш команд L1; и поскольку V2 не является адресом обычных пользовательских данных, он не проходит через кэш данных L1. V2 первоначально подается в унифицированный кеш L2 (унифицированная инструкция + данные + кэш PTE). Смотрите "пример иерархии кеша" .
• Если кэш L2 (или L3 или любой другой виртуально индексированный кеш) содержит PTE, то VHPT выбирает PTE из кеш-памяти и устанавливает PTE для V1 в TLB, а физический адрес в этом PTE используется для преобразования исходный виртуальный адрес V1 в физический адрес ОЗУ, в конечном итоге извлекающий эти данные или инструкцию полностью аппаратно без какой-либо помощи со стороны ОС.
• Если все уровни виртуально индексированного кэша дают сбой, но этот второй поиск TLB завершается успешно для V2, тогда VHPT выбирает PTE из физически проиндексированного кэша или из основной памяти, устанавливает PTE для V1 в TLB и физический адрес в этом. PTE используется для преобразования исходного виртуального адреса V1 в физический адрес ОЗУ, в конечном итоге извлекая эти данные или инструкцию полностью аппаратно, без какой-либо помощи со стороны ОС.
• Если этот второй поиск TLB завершается неудачно, аппаратный обходчик VHPT отказывается с VHPT TRANSLATION FAULT.
• Когда происходит СБОЙ ПЕРЕВОДА VHPT, ЦП перехватывает ОС. ОС должна выяснить, что пошло не так, и исправить ситуацию:
• (a) возможно, страница, содержащая V2, в настоящее время выгружается на диск, поэтому ОС считывает ее в ОЗУ и перезапускает сбойную инструкцию, или
• (б) возможно, глючная программа пытается прочитать или записать или выполнить какое-то неверное местоположение, и ОС завершает процесс, или
• (c) множество других приемов, которые делают авторы ОС, чтобы использовать этот механизм для захвата различных видов доступа - загрузить страницу, содержащую V1, которая может быть выгружена на диск; различные ловушки, используемые для отладки новых программ; моделировать "W ^ X" на процессорах, которые его не поддерживают напрямую; поддерживать копирование при записи; и т.п.

Диаграмма на странице 2 Томаса В. Барра, Алана Л. Кокса, Скотта Рикснера. «Кэширование перевода: пропустить, не ходить (таблица страниц)», которое рисует линию между «записями, хранящимися в кэше MMU» и «записями, хранящимися в кэше данных L2». (Это может быть полезным документом для людей, разрабатывающих новые процессоры , который полностью посвящен теме «Дизайн электроники»).

Стефан Эраниан и Дэвид Мосбергер. «Виртуальная память в ядре IA-64 Linux» и Ульрих Дреппер. «Что каждый программист должен знать о памяти» (Это может быть полезным документом для людей, пишущих операционные системы, работающие с таблицей страниц IA-64, что немного не по теме для ED - возможно, переполнение стека с помощью «операционных системный тег или тег «osdev» или вики OSDev.org были бы лучшим местом для этой темы).

Таблица A-10 на стр. 533 Intel. «Руководство разработчика программного обеспечения Intel® 64 и IA-32 для архитектур» «PAGE_WALKS.CYCLES ... может указывать на то, удовлетворяет ли большинство переходов по страницам кешами или вызывает пропадание кэша L2».

Я склонен согласиться с тем, что это относится к обмену стеками компьютерной архитектуры, а не к обмену стека электроники, но, поскольку это здесь:

@Davidcary правильно.

Немного истории:

Прогулки по таблицам Intel x86 НЕ кэшировались вплоть до P5, иначе Pentium. Точнее, обращения к памяти таблицы страниц не кэшировались, обошли кеш. Поскольку большинство машин до этого времени проходили сквозную запись, они получали значения, соответствующие кешу. Но они не отследили тайники.

P6, иначе Pentium Pro и AFAIK во всех последующих обходах таблиц процессоров были разрешены доступ к кешу и использование значения, извлеченного из кеша. Таким образом, они работали с кешами обратной записи. (Конечно, вы можете поместить таблицы страниц в не кэшируемую память, определенную, например, MTRR. Но это большая потеря производительности, хотя это может быть полезно для отладки ОС.)

Кстати, этот «доступ к памяти для обхода таблицы страниц может обращаться к кэшам данных» отдельно от «записи таблицы страниц могут храниться (кэшироваться) в TLB Ttranslation Lookaside Buffer)». На некоторых машинах TLB называется «Кэш перевода».

Другая связанная проблема заключается в том, что внутренние узлы таблиц страниц могут кэшироваться в еще большем количестве TLB-подобных структур данных, например, в кэш-памяти PDE.

Одно ключевое отличие: кеш данных связен и отслежен. Но кэши TLB и PDE не отслеживаются, то есть не являются связными. Суть в том, что, поскольку таблицы страниц могут кэшироваться в некогерентных TLB и PDE-кэшах и т. Д., Программное обеспечение должно явно сбрасывать либо отдельные записи, либо групповые группы (например, весь TLB), когда записи таблицы страниц, которые могли быть кэшированные изменены. По крайней мере, когда меняли «опасным» образом, переходя от RW-> R-> I или меняя адреса.

Я думаю, будет справедливо сказать, что каждый раз, когда добавляется новый тип некогерентного TLB-подобного кэширования, некоторые ОС ломаются, потому что у них были неявные предположения, что это не было сделано.