отношения между CPUECTLR.SMPEN, кэшей и MMU

Question

Читаю ARM документ (ARM ® Cortex ® -A57 MPCore Processor) и посмотреть следующие описания о

Вы должны установить CPUECTLR.SMPEN 1 до кэшей и MMU, или выполняются операции кэширования инструкций или TLB.

CPUECTLR.SMPEN для:

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

Тем не менее, для меня по-прежнему непонятна реальная причина (то есть, почему мы должны установить CPUECTLR.SMPEN в 1 до включения кэшей и MMU). Пожалуйста помоги мне с этим. Благодарю.

Answer 1

Проще говоря, SMPEN по существу контролирует, участвует ли ядро ​​в протоколах согласованности или нет.

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

Скажите, что у всех есть свои MMU и кеши, и ядро ​​A переводит некоторую страницу памяти - она ​​записывает нули в PTE, делает недействительными TLB для этого VA, а затем записывает обновленный PTE. Core B также может иметь запись TLB для этого VA: если TLBI не транслируется, ядро ​​B не будет знать, что его запись для этого VA уже недействительна и может читать фиктивные данные или хуже испортить старую физическую страницу, возможно, он был повторно использован для чего-то другого.

ОК, возможно, у базового Б нет адреса, кэшированного в его TLB, но он получает доступ к нему после обновления и запускает прохождение таблицы страниц. Без cache coherency это может быть несколько способов:

• В основе B лежит таблица страниц, кэшированная в ее L1; если он не сможет отследить L1 ядра A, чтобы узнать, что у кого-то еще есть грязная копия этой строки, а его собственная копия теперь недействительна, она будет читать устаревший старый PTE и ошибаться.
• Core B не имеет таблиц страниц, кешированных в L1; если он не может сгладить грязную линию от L1 ядра A, чтение переходит в L2 или в основную память, попадает в устаревший старый PTE и идет не так.
• Core B не имеет таблиц страниц, кэшированных в L1, но первая запись ядра A уже распространяется на L2 или далее; если считывание основного Б не может отследить вторую запись от L1 ядра A, он считывает промежуточный недействительный PTE из L2 и принимает ошибку.
• Core B не имеет таблиц страниц, кешированных в L1, но обе записи ядра A уже распространяются на L2 или далее; ядро Б читает новый PTE в L2, и все успевает работать как ожидалось по чистой случайности.

Теперь, есть некоторые ситуации, в которых вы не могли бы хотеть это - в асимметричной многопроцессорной, где два ядра могут делать совершенно не связанные вещи, под управлением различных операционных систем, а также работающих в отдельных областях памяти, может возникнуть небольшая выгода от отсутствия ненужного согласования chit-chat в фоновом режиме - в редких случаях ядра могут захотеть общаться друг с другом там, они, вероятно, сделают это с помощью межпроцессорных прерываний и определенной общей области нераскрытой памяти. Однако для SMP вы действительно хотите, чтобы ядра знали друг о друге и были частью одного и того же домена согласования до, у них есть шанс начать фактически распределять строки кэша и записи TLB, и именно поэтому управление всеми широковещательная и когерентная техника обернута в один, несколько смутно названный бит «SMP enable».

Чтобы понять, как вступить и выйти из последовательности, когда вы входите, вы должны быть уверены, что весь ваш кеш данных недействителен, чтобы избежать противоречивых записей. Если ЦП входит в SMP с действующими строками, уже находящимися в кеше, для адресов, принадлежащих линиям в когерентных кешах других ЦП, протокол согласованности нарушен и происходит потеря данных/коррупция. И наоборот, при выходе в автономный режим ЦП должен гарантировать, что его кеш чист, чтобы избежать потери данных - он может предотвратить сам , загрязняя любые записи, отключив его кеш/MMU, но также должен выйти из когерентности, чтобы предотвратить перенос грязных строк от другие CPU за его спиной. Только тогда безопасно выполнять операции установки/пути, необходимые для очистки всего локального кеша до потери содержимого при отключении питания.