2016-09-07 1 views
0

Другой вопрос относительно кэширования в ArmV7-A. В этом случае рассматриваемый SoC - Allwinner A20, двухъядерный Cortex-A7.PoU с несовместимым атрибутом

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

Что касается рассматриваемого SoC, поскольку оба ядра разделяют PoU на L2 (Unified) Cache, это означает, что все, что помещено в L1, будет видимым для L2. Это правильно?

Даже если я изменяю атрибут области памяти, который должен быть несовместимым, L2 сможет видеть, что внутри L1 в ядре. Это правда?

Разрабатывать то, что я имел в виду, что я сделал небольшой эксперимент:

Когда я писал в адрес памяти Внутри Non-Shareable, Write-Back области от основных # 0. Затем, не выполняя любую операцию кэширования, когда я пытался читать из одного и того же адреса памяти из ядра # 1, случилось так, что он прочитал правильное значение, которое было написано с ядра # 0.

Я предположил, что поведение было результатом того, что L2 является PoU, поэтому, когда я писал из ядра # 0, L2 также сохраняет его копию (даже если она не очищена). Затем, когда я читаю из ядра # 1, после прочтения прочтения, L1 ядра # 1 возвращает значение памяти из L2.

+0

Запись из одного процессора и _reading_ из другого не имеет ничего общего с PoU, поскольку оба являются _data_ accesses. – Notlikethat

+0

@Notlikethat Спасибо также за другой вопрос. Не могли бы вы уточнить? Разве PoU не имеет никакого отношения к доступу к данным? Я до сих пор не знаю, почему другой процессор может получить доступ к контенту, который я написал в первом процессоре. При условии, что регион settin не связан, Writeback –

ответ

1

... так как оба ядра разделяют PoU на L2 (Unified) Кэш, это означает, что все, что помещается в L1, будет видимым для L2. Это правильно?

№ Один доступ к данным ЦП может отслеживать тайники данных другого в том же домене совместного доступа, но это не имеет никакого отношения к PoU для доступа к инструкциям; это всего лишь протокол согласованности.

Даже если я изменяю атрибут области памяти, который должен быть несовместимым, L2 сможет видеть, что внутри L1 в любом ядре. Это правда?

Нет. Неразделяемая память не гарантируется согласованием. Конечно, вы, , возможно, видят, что это работает - возможно, Cortex-A7 все еще держит неприличные кэш-линии, или, может быть, ваши данные только что были выселены из L1D тем временем, что другой процессор ударил его по L2 - но это определенно не следует полагаться. В любом случае, наличие нескольких процессоров для доступа к одному и тому же несовместимому местоположению - это совершенно обратная задача, которую нужно делать на практике; вы сознательно сказали, что не хотите делиться ею!

+0

Спасибо! Я не проверял, действительно ли ReadNoSnoop для области несовместимой памяти является реализацией, определенной или требуемой для Cortex-A7. То, что я делаю, фактически проверяет мое предположение о неприменимом регионе, и мое предположение состояло в том, что оно должно быть исключительно для процессора. Ваш ответ действительно ответил на некоторые мои сомнения, однако я оставлю этот вопрос без ответа. –

+0

Я бы предположил, что L2 отправит транзакцию ReadNoSnoop на интерфейс ACE, если там не хватает общей нагрузки, поэтому я не ожидал такой «случайной» согласованности между кластерами в многокластерной системе - внутри одного кластера , однако, вещи более тесно связаны друг с другом, и вы в основном смотрите на детали реализации SCU. – Notlikethat

+0

вот что я видел из доступа к внутренней памяти, используя кодировку, указанную в Cortex-A53 TRM: после того, как я написал из cpu0, строка кэша в L1D cpu0 «изменена», тогда только после того, как я прочитал с процессора 1, L1D Линия кэша cpu1 стала 'Owned', а L1D cpu0 стал' Shared'. –