Что происходит с содержимым кеша при переключении контекста?

50

В многоядерном процессоре, что происходит с содержимым кэша ядра (скажем, L1), когда происходит переключение контекста в этом кэше?

Зависит ли поведение от архитектуры или от всех производителей микросхем?

Анкит
источник

Ответы:

42

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

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

С физическими адресами не имеет значения, какой процесс обращается к адресу, содержимое может быть передано. Поэтому нет необходимости аннулировать содержимое кэша во время переключения контекста. Если два процесса отображают одну и ту же физическую страницу с разными атрибутами, это обрабатывается MMU (действующим как MPU (блок защиты памяти)). Недостатком кэш-памяти с физическим адресом является то, что MMU должен находиться между процессором и кешем, поэтому поиск кеша идет медленно. Кэши L1 почти никогда не являются физическими адресами; могут быть кэши более высокого уровня.

Один и тот же виртуальный адрес может обозначать разные области памяти в разных процессах. Следовательно, с виртуально адресованным кешем процессор и операционная система должны взаимодействовать, чтобы гарантировать, что процесс найдет нужную память. Есть несколько общих методов. Код переключения контекста, предоставляемый операционной системой, может сделать недействительным весь кеш; это правильно, но очень дорого. Некоторые архитектуры ЦП имеют место в своей строке кэша для ASID (идентификатора адресного пространства) аппаратной версии идентификатора процесса, также используемого MMU. Это эффективно отделяет записи кэша от разных процессов и означает, что два процесса, отображающие одну и ту же страницу, будут иметь несогласованные представления одной и той же физической страницы (обычно существует специальное значение ASID, указывающее общую страницу, но они должны быть сброшены, если они не отображаются на один и тот же адрес во всех процессах, где они отображаются). Если операционная система позаботится о том, чтобы разные процессы использовали неперекрывающиеся адресные пространства (что лишает некоторые цели использования виртуальной памяти, но иногда может быть выполнено), то строки кэша остаются действительными.

Большинство процессоров, которые имеют MMU, также имеют TLB . TLB - это кэш отображений из виртуальных адресов в физические адреса. TLB консультируется перед поиском в кэшах с физическим адресом, чтобы по возможности быстро определить физический адрес; процессор может начать поиск в кэше до завершения поиска в TLB, так как часто возможные строки кэша могут быть идентифицированы из средних битов адреса между битами, которые определяют смещение в строке кэша, и битами, которые определяют страницу. Кэши с виртуальной адресацией обходят TLB в случае попадания в кеш, хотя процессор может инициировать поиск TLB во время запроса кеша в случае пропадания.

Сам TLB должен управляться во время переключения контекста. Если записи TLB содержат ASID, они могут оставаться на месте; операционная система должна очищать записи TLB только в том случае, если их ASID изменил значение (например, из-за выхода из процесса). Если записи TLB являются глобальными, они должны быть аннулированы при переключении в другой контекст.

Жиль "ТАК - перестань быть злым"
источник
2
Очень информативно. Если бы вы могли добавить несколько примеров того, как это делается в реальных архитектурах, было бы еще лучше.
JohnTortugo
2
@JohnTortugo То, что я написал, довольно близко соответствует тому, что вы можете делать в ARMv7 (например, процессор вашего смартфона) (единственная архитектура, где я когда-либо писал код обработки MMU). Я ожидаю, что другие платформы, такие как x86, будут довольно похожими, но я не могу написать о них. Если вы ищете конкретную информацию о реальной платформе, Computer Science не правильный сайт, вы можете спросить о переполнении стека или электротехнике или Embeddedd (предложение) .
Жиль "ТАК - перестань быть злым"
10

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

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

Эвристика может быть простой как LRU (используется реже всего). Но с современными процессорами эвристика более сложна.

Взгляните на Руководство разработчика программного обеспечения для архитектур Intel® 64 и IA-32, том 3, глава 11, в котором описываются кэш-память и механизмы управления кэш-памятью. У AMD это есть в главе 7 Руководства по программированию для архитектуры AMD64, том 2: Системное программирование . Кажется, что для процессоров на базе ARM PDF-файлы доступны только зарегистрированным пользователям.

улы
источник
Можете ли вы дать ссылку на первый абзац? Или связанные документы относятся к этой проблеме?
Рафаэль
Поведение сильно зависит от того, физически или виртуально адресован кеш. Политика замены здесь не актуальна. Для ARM есть информация в технических руководствах по процессорам, которые являются общедоступными, например, L1 на Cortex-A9 (то, что вы получаете в сотовых телефонах последнего поколения), хотя это может быть трудно понять без непубличного справочного руководства по архитектуре .
Жиль "ТАК - перестань быть злым"
1
@ Рафаэль Я написал «как правило», потому что с процессорами, с которыми я сталкивался, кеш сам по себе не имеет никаких знаний о потоках, процессах, контекстах и ​​т. Д. Он просто реагирует на доступ к памяти. Если кэш данных очищается и кэш команд становится недействительным при переключении контекста, то именно ОС запускает это действие, а не кэш. Если вы устанавливаете другую ОС, это поведение может измениться.
Uli
@ Жиль На этот раз я попытался дать краткий ответ и решил не писать о виртуальной памяти, потому что это сразу связано с ОС. И есть сроки, чтобы рассмотреть тоже. «Ничего не меняется» может быть ответом на время между переключением контекста и следующим доступом к памяти, поскольку содержимое кэша может быть признано недействительным, но не изменено вообще.
Uli