«Стрекоза» — необычное имя для операционной системы семейства BSD. И это неспроста: система действительно странная, неоднозначная и полная противоречивых технических решений. У DragonFly гибридное ядро, что сближает ее с микроядерными операционками, она использует инновационный для своего времени подход для работы на SMP-системах, в ее состав включена непривычная по дизайну, но очень эффективная файловая система HAMMER, обладающая возможностями ZFS/btrfs и способная работать на кластере.

 

Многоядерный бум

История DragonFly, как и история OpenBSD, началась с конфликта. Но если во втором случае конфликт был вызван не совсем джентльменским поведением человека, то в первом проблемой стало виденье будущего. В то время (начало 2000-х) кипела работа над следующей версией FreeBSD — 5.0, в которую должно было войти много новшеств (devfs, GEOM), а также были сделаны первые шаги для избавления от так называемой глобальной блокировки ядра (Big Giant Lock) при работе системы на многоядерных/многопроцессорных платформах (SMP).

Именно принятый план избавления от глобальной блокировки и стал причиной конфликта между разработчиками. Как известно, SMP-системы отличаются тем, что имеют единое адресное пространство для всех процессорных ядер. Другими словами, все ядра используют одну память, которая никак между ними не делится, всем доступно все. Возникает очевидная проблема: что будет, если два потока исполнения ядра попытаются получить доступ или изменить одну и ту же структуру данных (значение переменной sysctl, например) одновременно? Ответ: возникнет коллизия (поток, который должен был сделать это вторым, может сделать это первым, или наоборот — со всеми вытекающими отсюда последствиями). Самое простое решение этой проблемы: запретить исполнение всего кода ядра одновременно несколькими процессорами с помощью глобальной блокировки, как и было сделано в FreeBSD 4. Пока один процессор исполняет код ядра, второй ждет.

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

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

Один из активных разработчиков ядра FreeBSD и Linux Мэттью Диллон (Matthew Dillon) предложил решить эти и другие возможные проблемы, отказавшись от блокировок и заменив их на три ключевые технологии: механизм сообщений, привязку данных ядра к процессорам/ядрам и распараллеливание подсистем ядра между процессорами и ядрами.

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

В результате можно было убить целый взвод зайцев одним выстрелом:

  • Блокировки для доступа к данным процессов внутри ядра не требовались, так как данные структуры обслуживались независимо для каждого процессора.
  • Блокировки для доступа к данным ядра в большинстве случаев не нужны, вместо них использовался бы механизм сообщений (поток просто отправляет запрос, и он ставится в очередь на обработку).
  • Достигалась гораздо более высокая производительность благодаря распараллеливанию подсистем ядра: намного эффективнее запустить по одному стеку TCP/IP на каждое процессорное ядро и обеспечить их слаженную работу с помощью сообщений, чем расставлять по всему сетевому стеку блокировки или блокировать весь сетевой стек целиком.

Представители FreeBSD Core Team, однако, были категорически против столь глобальных и резких изменений и настаивали на использовании блокировок: нельзя просто так взять и сломать ядро топором. Мэттью же считал, что систему необходимо разом перевести на новые рельсы, потому как постепенный переход невозможен, а блокировки затянут дело на годы. Слово за слово, Диллон покидает Core Team и отправляется в свободное плаванье.

 

DragonFly

Так в июне 2003 года появляется новая операционная система DragonFly BSD, основанная на кодовой базе FreeBSD 4.8. Именно в ней Мэттью Диллон практически в одиночку реализует все свои идеи. Внутриядерный аллокатор памяти, сетевой код, подсистемы ввода-вывода и виртуальной файловой системы теперь разделены на несколько копий, по количеству процессоров/ядер, появляется позаимствованный из микроядерных систем механизм сообщений, а также сериализующие токены (Serializing tokens) вместо mutex в тех местах, где без блокировок обойтись нельзя (например, при доступе к тем же переменным sysctl).

Продолжение статьи доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все статьи на сайте

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

Вариант 2. Купи одну статью

Заинтересовала статья, но нет возможности оплатить подписку? Тогда этот вариант для тебя! Обрати внимание: этот способ покупки доступен только для статей, опубликованных более двух месяцев назад.


Комментарии

Подпишитесь на ][, чтобы участвовать в обсуждении

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

Check Also

Скрытая сила пробела. Эксплуатируем критическую уязвимость в Apache Tomcat

В этой статье мы поговорим о баге в Apache Tomcat, популярнейшем веб-сервере для сайтов на…