Прогнозировать тенденции — неблагодарное занятие даже для искушенных экспертов. Но, по крайней мере, одну тенденцию легко проследить: это широкое распространение многоядерных СнК, что связано с несколькими причинами, о чем и пойдет речь в этой статье.
Во-первых, прошло много лет, с тех пор как в рабочей станции стала применяться архитектура многоядерного процессора для решения таких задач как рост производительности и снижение потребляемой мощности. Если к настоящему времени рабочие станции стали полностью поддерживаться операционными системами общего назначения (ОСОН), разработчики встраиваемых решений ищут методы применения многоядерной архитектуры.
Во-вторых, несколько поставщиков СнК предлагает рынку многоядерные решения, в числе которых компании Cavium, Freescale, MIPS и ARM. Однако данные решения ограничены потребностями той или иной сети и используются скорее для того, чтобы улучшить ее производительность, а не для снижения потребляемой мощности.
Остальные компании рынка встраиваемых систем ограничили доступные параметры оборудования, исходя из основного определяющего фактора — малой потребляемой мощности. Если процессор ARM 11 MPCore опередил свое время, то для Cortex-A9 MPCore наступил звездный час — этот процессор получает все большее внимание со стороны рынка встраиваемых систем.
Как следствие, поставщики СнК приняли Cortex-A9 MPCore в качестве основы своих проектов следующего поколения. Более года назад компания Texas Instruments заблаговременно проанонсировала платформу OMAP следующего поколения — OMAP 4 с двухъядерным процессором Cortex-A9 MPCore, производство которой намечено на вторую половину 2010 г. ST Microsystems сообщила о выпуске бытовых устройств следующего поколения на базе Cortex-A9 MPCore.
В сфере потребительской электроники также возникла потребность в многоядерных платформах в результате растущего спроса на большие вычислительные возможности и более сложные пользовательские интерфейсы. Таким образом, пришло время совершенствования и программного обеспечения, которое должно соответствовать функциональности многоядерного оборудования.
Развитие SMP и AMP
Многоядерные процессоры можно разделить на две категории: асимметричный мультипроцессор (Asymmetric Multi Processor, AMP) и симметричный мультипроцессор (Symmetric Multi Processor, SMP). Как правило, в AMP ядра архитектурно отличаются друг от друга — каждое из них выполняет свою систему команд с соответствующей операционной системой (ОС) или даже без нее.
В AMP операционная система, как правило, выполняется на одном ядре в соответствии с некоторым методом (вероятнее всего, собственной разработки) для осуществления взаимодействия между ядрами. Она управляет всеми устройствами, находящимися в ее распоряжении, с минимальным совместным использованием ресурсов. В отличие от AMP, SMP состоит из идентичных ядер центрального процессора, которые обслуживают те же события, имеют одинаковый набор команд, пользуются той же памятью и совместно используют одинаковые устройства, прерывания и контроллер когерентности кэш-памяти. SMP позволяет равномерно распределять нагрузку между ядрами.
Операционная система процессора SMP может использовать все ядра, находящиеся в ее распоряжении, назначая потоки, обслуживающие устройства и прерывания на любом ядре SMP.
Можно ли воспользоваться преимуществами AMP на процессоре SMP? Да, это возможно. Нецелесообразно управлять всеми ядрами в режиме SMP только потому, что это SMP-оборудование. В некоторых оптимизациях система может и должна разделяться между несколькими ОС. К такой оптимизации относится реализация функций AMP на процессоре SMP.
Гибридный метод (см. рис. 1) может быть идеальным решением в том случае, когда SMP-оборудование делится между несколькими частями ОС, причем каждая из них функционирует на нескольких ядрах. Например, рассмотрим СнК на базе 4-ядерного процессора SMP.
 |
| Рис. 1. Гибридная архитектура AMP/SMP на SMP-архитектуре |
Разделим операционную систему на две области, например, ОСРВ (Real-Time Operating System, RTOS) и некоторую разновидность ОСОН (General Purpose Operating System, GPOS). Ядра 0 и 1 относятся к области 0, а ядра 2 и 3 — к области 1. Если все ОС поддерживают работу как SMP-, так и AMP-процессоров, реализуется наиболее совершенная конфигурация.
Разработчики приложений или системные интеграторы обычно испытывают трудности, связанные с миграцией кода для одного ядра на несколько ядер SMP-системы. В этой связи возникают два важных вопроса: готов ли код для многоядерного процессора; код учитывает преимущества многоядерной системы?
Готов ли код для многоядерного процессора?
При подготовке кода к запуску на планировщике SMP необходимо учесть все приоритеты, которые могут нарушить порядок исполнения кода. Известны следующие две основные причины потенциальных проблем при исполнении кода на многоядерной системе.
1. Использование мастера прерывания в качестве глобального семафора. Семафор является объектом, который предотвращает одновременный доступ к совместно используемому ресурсу. Однако его, как правило, применяют в ОС на единственном ядре в качестве «быстрого» семафора в масштабе всей системы. Он выглядит следующим образом:
Disable Interrupts
Access and update the global data structure
Enable Interrupts
Из этого псевдокода видно, что при осуществлении доступа к структуре глобальных данных не выполняется даже прерывание, что хорошо соблюдается для систем с одним ядром и выполняется намного быстрее, чем с помощью семафора.
Однако при функционировании двух ядер и выполнении кода прерывания отключены только на том ядре, на котором он выполняется в текущий момент времени, и структура данных открыта для доступа других назначенных ядер SMP. Это условие состязания делает систему открытой для непредсказуемых результатов.
2. Использование приоритета для правильного обслуживания системы. Планирование на основе приоритета, пригодное для системы с одним ядром, может потерпеть неудачу в случае многоядерной платформы, если оно используется только как гарантия исполнения потока с наивысшим приоритетом.
При назначении исполнения задачи низшего приоритета на отдельном ядре метод блокировки одновременного доступа двух потоков к данным приводит к возникновению условия состязания. Одним из решений этой проблемы является исключение модификаций структуры глобальных данных с помощью потоков наивысшего приоритета в каждой подсистеме. Общепринятая практика в отношении одного ядра создает потенциально опасное условие состязания для многоядерной системы.
Наконец, даже если составлен план работы операционной системы на SMP с несколькими ядрами, необходимо предусмотреть достаточное количество потоков для использования всех ядер. Следует изменить архитектуру приложения таким образом, чтобы нагрузка была равномерно распределена между всеми ядрами. Такой подход не только сделает SMP-систему безопаснее, но и оптимизирует ее работу со всеми ядрами.
AMP-системы
AMP можно использовать в SMP-оборудовании. На самом деле, это идеальное взаимоотношение между несколькими объектами операционной системы. Исполнение кода одновременно с его разделением между областями операционной системы является эффективным методом повышения ее безопасности и производительности.
Такой подход обеспечивает каждую операционную систему детерминистской средой с выделенным кэшем для исполнения. В идеальном случае можно назначить AMP одно или несколько ядер и воспользоваться механизмом межпроцессорной связи (Inter-Processor Communication, IPC) для взаимодействия между разными ОС.
Если в системе исполняется одноядерный код безопасности, можно назначить ядро набору потоков, которые должны находиться в одноядерном режиме и использовать IPC для взаимодействия между ядрами. Несмотря на то, что эти действия не позволят полностью распределить нагрузку между ядрами, код действительно будет исполняться, даже если он не предназначен для работы на многоядерных системах.
Способность системы присвоить несколько исполняемых потоков определенному ядру из среды планирования SMP реализуется в технологии ограниченных вычислительных областей (Bounded Computational Domains, BCD), разработанной компанией Mentor Graphics для ОСРВ Nucleus. Технология BCD позволяет всей системе работать в качестве единой ОС, гарантируя при этом исполнение на ядре только назначенных ему потоков. Этот метод идеален для унаследованных приложений, которые не в состоянии работать с SMP, но нуждаются в тесной интеграции с другими задачами системы.
Большинство операционных систем использует механизм IPC для взаимодействия между областями ОС. Проблема применения IPC-механизмов в том, что они запатентованы и одновременная работа двух операционных систем, например ОСРВ и Linux, с разными методами IPC может оказаться достаточно проблематичной.
Для решения проблемы использования запатентованных IPC-механизмов ассоциация Multicore Association создала стандарт на основе API под названием Multicore Communication API (MCAPI). Если поставщики ОСРВ и ОСОН принимают MCAPI, любой код, записанный для API, портируется в другую систему, а все IPC-коды остаются неизменными. Стандарт MCAPI позволяет при необходимости переносить код в соответствии с требованиями к синхронизации.
Заключение
Использование многоядерных СнК стало привычным решением в 2010 г. Операционные системы быстро приспосабливаются к работе с оборудованием, оснащенным процессорами SMP и AMP. Кроме того, поставщики ОС принимают новые стандарты в отношении механизмов межпроцессорного взаимодействия, к числу которых относится MCAPI. Этот стандарт намного больше облегчает работу нескольких ОС в многоядерной системе, чем поначалу можно было бы ожидать.