«Стрекоза» - незвичайне ім'я для операційної системи сімейства BSD. І це неспроста: система дійсно дивна, неоднозначна і повна суперечливих технічних рішень. У DragonFly гібридне ядро, що зближує її з мікроядерний операційками, вона використовує інноваційний для свого часу підхід для роботи на SMP-системах, в її склад включена незвична по дизайну, але дуже ефективна файлова система HAMMER, що володіє можливостями ZFS / btrfs і здатна працювати на кластері.
багатоядерний бум
Само собою, такий підхід неефективний, і в FreeBSD 5 було заплановано почати поступове позбавлення від цього милиці за допомогою точкових блокувань (mutex), які будуть встановлені на всі більш-менш значущі структури даних. Так код ядра міг виконуватися декількома процесорами, а чекати доводилося тільки в разі одночасного доступу до одних і тих же структурам даних і підсистем.
Але і у цього підходу було кілька недоліків. По-перше, ядро перетворювалося в купу коду з масою локов, багато з яких до того ж залежали один від одного. По-друге, код ставав малоефективним: блокування застосовувалися повсюдно і без розрахунку на те, що певні типи даних в різний час можуть або не можуть мати проблеми з одночасним доступом, так як актуальні тільки для одного процесорного ядра. Наприклад, процеси можуть працювати всі на одному ядрі (і тоді блокування не потрібна) або бути розкидані по різних (блокування потрібна).
Один з активних розробників ядра FreeBSD і Linux Меттью Діллон (Matthew Dillon) запропонував вирішити ці та інші можливі проблеми, відмовившись від блокувань і замінивши їх на три ключові технології: механізм повідомлень, прив'язку даних ядра до процесорів / ядер і розпаралелювання підсистем ядра між процесорами і ядрами.
Для реалізації цих ідей планувалося запустити окремий планувальник процесів / потоків на кожен процесор. Для доступу до даних ядра передбачалося використовувати механізм повідомлень, який дозволив би уникнути блокувань, забезпечив правильну послідовність виконання операцій доступу і не накладав би ніякого оверхедів, коли кілька потоків, які претендують на доступ до одних і тих же даних, виконуються на одному процесорі. Код ядра по можливості планувалося распараллелить за різними процесорам / ядер.
В результаті можна було вбити цілий взвод зайців одним пострілом:
- Блокування для доступу до даних процесів всередині ядра були не потрібні, так як дані структури обслуговувались незалежно для кожного процесора.
- Блокування для доступу до даних ядра в більшості випадків не потрібні, замість них використовувався б механізм повідомлень (потік просто відправляє запит, і він ставиться в чергу на обробку).
- Досягалася набагато більш висока продуктивність завдяки распараллеливанию підсистем ядра: набагато ефективніше запустити по одному стеку TCP / IP на кожне процесорний ядро і забезпечити їх злагоджену роботу за допомогою повідомлень, ніж розставляти по всьому мережевого стеку блокування або блокувати весь мережевий стек цілком.