Не приведет ли это к потерям производительноти?
Без сомнения, на однопроцессорны системах мы увидим отрицательное воздействие на производительноть. Однако, как я пояснил в первой части, аппаратура для этой системы основывается на многоядерном процессоре, а это все меняет.

Для того, чтобы понять что произойдет, нам сперва следует разобраться в том, что конкретно ударяет по производительноти микроядра в первом случае.

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

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

Макроядерный подход не страдает от таких проблем с производительнотью, так как все в ядре и нет необходимости в переключении контекста, когда поток команд переходит с одной внутренней части ядра на другую.

Уже говорилось, что хорошо спроектированно микроядро не обязательно должно быть медленным, в какой-то мере можно избежать потерь производительноти на переключение контекстов, собирая сообщения вместе и передавая их вместе (асинхронно), это уменьшает потребность в переключении контекстов. Однако, большинство исследований микроядер производилось в Unix, и, исходя из синхронной природы API Unix [async], асинхронный обмен сообщениями не использовался, что приводило к бОльшим переключениям контекста и, из-за этого, понижению производительноти. Поэтому репутация микроядер, как медленных, как минимум частично незаслужена.

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

BeOS использовала технику асинхронных сообщенией и это, безусловно, очень быстрая ОС. Однако, сетевой стэк, будучи вне ядра, зарекомендовал себя как тяжкая потеря производительноти и позже был перемещен внутрь, что однозначно повысило производительноть при работе с сетью. Be никогда не выпускала таких коммерческих релизов, но это вошло в Zeta [Zeta] (единственный легальный способ получить полноценную BeOS сегодня).

Использование нескольких ядер

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

Использование множественных ядер совместно с асинхронной передачей сообщений приведет к тому, что наша экзо/микроядерная ОС сможет превзойти синхронную макроядерную ОС. Каждая передача сообщения или вызов функции будет требовать времени, и это время будет фиксировано. Асинхронная передача сообщений позволит передавать бОльшие объемы данных за один раз, а это уменьшит количество проходящих сообщений по сравнению с системой, использующей синхронные вызовы API.

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

Возможно вы возразите, что при таком распылении, приложение, работающее на нескольких ядрах заставит сменяться компоненты ОС и тем самым уменьшать производительноть. Конечно, это риск, но все тяжелые вычислительные задачи скорее всего будут работать на процессорах Cell, которые не будут работать над ОС. Помните, что это настольная машина, так что ядра процессоров скорее всего будут просто сидеть ничего не делая большую часть времени. Многие любят обсуждать относительные показатели производительноти ОС или аппаратуры, но очень немногие действительно используют эту производительноть.

Следует заметить, что ядро Linux 2.6 включает в себя асинхронный ввод/вывод. Асинхронный обмен сообщениями был включен и в ОС, основанную на FreeBSD, проектом DragonFly BSD [Dragon].

И все же не Linux?

Конечно, Linux (или *BSD) имеет свои преимущества, но похоже, что микроядерный подход может обеспечить не только все непременные аттрибуты микроядерной архитектуры, но и будет иметь в запасе лучшую производительноть. Такой подход также лежит в русле общего принципа простоты, который я обозначил в первой части, и дает нам шанс исследовать проектирование ОС с другой стороны и увидеть каковы результаты.

В то время как система будет большей частью работать как микроядерная ОС, тот факт, что в реальности она использует экзоядро даст приложениям возможность практически полностью игнорировать ОС и работать с аппаратурой напрямую безопасно и разделенно. Прямой доступ к аппаратуре - не очень одобряемый подход, но он может быть полезен для приложений, использующих FPGA, и имеет потенциал для создания значительных ускорений в работе приложений [Exo]. Он также позволяет еще кое-что, что будет еще более полезно...

индекс статьи
страница 1 : страница без заголовка
страница 2 - текущая : страница без заголовка
страница 3 : страница без заголовка