Можно ли использовать LDREX/STREX для реализации спин-блокировки без включения SCU в многоядерной SoC ARM Cortex-A9?

Я знаю, что это может быть странным использованием. Я просто хочу знать, могу ли я использовать LDREX/STREX с отключенным SCU.

Я использую двухъядерный процессор Cortext-A9 SoC. Два ядра работают в режиме AMP: у каждого ядра своя ОС. Хотя контроллер памяти является общим ресурсом, каждое ядро ​​имеет собственное пространство памяти. Один не может получить доступ к памяти другого. Поскольку когерентность кэша не требуется, SCU не включен. В то же время у меня также есть общая область памяти, к которой могут получить доступ оба ядра. Область общей памяти не кэшируется, чтобы избежать проблем с когерентностью кэша.

Я определяю спин-блокировку в этой области общей памяти. Эта спин-блокировка используется для защиты доступа к общим ресурсам. Прямо сейчас спин-блокировка реализована просто так:

void spin_lock(uint32_t *lock)
{
    while(*lock);
    *lock = 1;
}
void spin_unlock(uint32_t *lock)
{
    *lock = 0;
}

где блокировка — это переменная в общей памяти, поэтому оба ядра могут получить доступ к этой блокировке.

Проблема этой реализации в том, что доступ к блокировке не является исключительным. Вот почему я хочу использовать LDREX/STREX для реализации спин-блокировки. Пожалуйста, позвольте мне переформулировать мой вопрос:

Могу ли я использовать LDREX/STREX без включенного SCU?

Спасибо!


person yelInv    schedule 21.04.2015    source источник


Ответы (3)


Итак ... прямой ответ на ваш вопрос: да, это возможно - до тех пор, пока что-то еще в системе памяти реализует эксклюзивный монитор для области общей памяти. Если это не так, то ваши STREX всегда будут возвращать OK (а не EXOK), наблюдаемый как сбой в регистре результатов.

Однако, почему бы вам не включить SCU? Очевидно, что то, что вы пытаетесь сделать, требует согласованного представления памяти между двумя операционными системами, по крайней мере, для этого региона. А с кэшами данных PIPT вы не увидите никакого сглаживания строк кэша в зависимости от того, как они отображаются в каждом изображении.

person unixsmurf    schedule 22.04.2015
comment
Спасибо @unixsmurf. Единственная проблема, которую я не решаюсь включить SCU, - это производительность. У нас очень строгие требования к производительности, и в настоящее время мы только на краю требований. Мы можем оптимизировать некоторый код для повышения производительности. Но включение SCU может существенно повлиять на производительность. У кого-нибудь есть картинка, насколько SCU влияет на производительность системы? Мы используем ОС Nucleus 3.x. - person yelInv; 27.04.2015
comment
Я не думаю, что SCU вообще влияет на производительность, за исключением случаев, когда его работа требует удаления/миграции строк кэша. Что в вашем случае использования будет только для областей памяти, фактически разделяемых между изображениями, где это все равно будет более эффективным, чем программный механизм без кэширования. Конечно, измерение того, что это действительно так, было бы хорошей практикой. - person unixsmurf; 27.04.2015

В целом ответ - нет. Здесь есть две проблемы:

1) Вы не можете использовать эксклюзивную загрузку/сохранение в некэшированной памяти. Эксклюзивные операции работают только с «нормальной» идемпотентной памятью.

2) В руководстве ARM не указано, как эксклюзивные мониторы работают в сочетании с когерентностью памяти, но любая разумная реализация, по сути, поместит монитор в механизм получения строки кэша. Если вы отключили отслеживание строк кэша, вы, скорее всего, сделали мониторы неработоспособными на вашем чипе.

person Variable Length Coder    schedule 21.04.2015
comment
Хм, AFAICS нет ничего в ARM ARM, который говорит, что обычная некэшируемая память не будет работать - только то, что устройство и сильно упорядоченный являются нет-нет. При условии, что атрибут совместного доступа указан правильно, эксклюзивы будут обрабатываться глобальным монитором в системе памяти, а не локальным монитором каждого ядра. - person Notlikethat; 22.04.2015
comment
+1 (некоторое время назад) за предоставление информации, которой нет в ARM ARM. Хотя ваш ответ не на 100% правильный, он показывает некоторые критические мысли и прагматические советы, которые, я не думаю, находятся где-либо еще и, вероятно, должны быть подчеркнуты людьми в StackOverflow. - person artless noise; 22.04.2015
comment
вы можете использовать ldrex/strex в некэшированной памяти, шина axi работает там и имеет эксклюзивные сигналы доступа, проблема в том, что она находится на территории конкретного поставщика чипов, поэтому ответ специфичен для каждой версии каждого чипа от каждого поставщика, который больше набор майби чем арм ядра какие то да если кеш то на нем работает. - person old_timer; 23.04.2015

Ваш единственный (плохо сформулированный) вопрос,

Могу ли я использовать LDREX/STREX без включенного SCU?

В идеальной вселенной ARM да, это возможно. Т.е. возможно, что где-то, когда-нибудь вы сможете это сделать. Я думаю, ты имеешь в виду,

Могу ли я использовать LDREX/STREX без включенного SCU в моей системе?

К сожалению, ARM ARM является чем-то вроде политического/бюрократического документа. Вы должны быть предельно осторожны при чтении слов «настоятельно рекомендуется», «НЕПРЕДСКАЗУЕМО», «НЕИЗВЕСТНО» и можно. Все программисты хотели бы, чтобы ldrex/strex применялось ко всей памяти. На самом деле, если бы контроллер BUS (обычно AXI-NIC) реализовывал монитор, то не было бы проблем с поддержкой всеми любимой инструкции swp. На StackOverflow есть различные сообщения, в которых люди хотят заменить swp на ldrex/strex.

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

ARM ARM написан как общий документ для людей, которые хотят внедрить процессор Cortex-A. Написано для того, чтобы руки (творчество) не были связаны для реализации монитора с-в кеше.

Поэтому вам нужно прочитать конкретную документацию по вашему конкретному SOC Cortex-A9. Он вероятно будет поддерживать только ldrex/strex с кэшированной памятью. На самом деле рекомендуется выполнить pld, чтобы убедиться, что память находится в кеше, прежде чем выполнять ldrex, и это будет означать, что вам нужно активировать SCU в вашей системе. Я предполагаю, что вы обеспокоены некоторыми дополнительными циклами, которые SCU добавит к задержке?

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

Наверняка, если вы хотите, чтобы в будущем ваш код/ОС был перенесен на более новые или другие процессоры Cortex-A, вам не следует делать это предположение, даже если ваш набор микросхем поддерживает «глобальный монитор» вне подсистем кэша.

person artless noise    schedule 22.04.2015
comment
Сигналы для поддержки мониторов в протоколе ACE/AXI кажутся ARLOCK, RACK, EXOKAY и OK. Шина ARM SOC может быть сложным, и вам нужна поддержка всех задействованных мастеров/ведомых и возможных других сквозных элементов, таких как TZASC и т. д., чтобы ответ был «да» (и чтобы они были правильно подключены). В то время как документы по протоколу определяют сигналы, даже некоторые IP от ARM, предназначенные (и используемые) в некоторых конструкциях Cortex-A, не упоминают эти сигналы. - person artless noise; 22.04.2015
comment
В документах на стороне кремния говорится, что вам не нужно поддерживать EXOKAY для однопроцессорных систем, но в документах на стороне программного обеспечения говорится, что вместо этого не используйте вспомогательное использование ldrex/strex. Кэши ARM поддерживают ldrex/strex в однопроцессорной или многопроцессорной системе, но то, что произойдет в случае промаха кеша, зависит от поставщика чипа, поэтому ответ таков: зависит. ldrex/strex предназначены для многоядерных процессоров для совместного использования ресурсов между ядрами, а не для того, чтобы одно ядро ​​выполняло блокировку для себя. - person old_timer; 23.04.2015
comment
Спасибо @artlessnoise за подробное объяснение. Да, вы правы, я не уверен, где реализован глобальный монитор. И я не решался включить SCU только для очень небольшой части когерентности памяти из-за потенциальной проблемы с производительностью. Не уверен, насколько SCU повлияет на производительность. Но у нас очень строгие требования к производительности. Можно ли реализовать спин-блокировку без использования LDREX/STREX? - person yelInv; 27.04.2015
comment
Нет, это невозможно (если LDREX/STREX не работает, то и swp не работает). Я думаю, что UnixSmurf подчеркивал, что если вы включаете кеш, вам нужен SCU. Штраф SCU намного меньше, чем всегда отсутствующий кеш. Если вам нужен хард-РТ, то заблокируйте что-нибудь в кеше и т. д. Я думаю, что ваша причина отключения SCU кажется ошибочной? ... но это не отвечает на прямой вопрос. - person artless noise; 27.04.2015