Mach ( / m ɑː k / ) [1] — ядро , разработанное в Университете Карнеги-Меллон Ричардом Рашидом и Ави Теваняном для поддержки исследований операционных систем , в первую очередь распределенных и параллельных вычислений . Mach часто считают одним из самых ранних примеров микроядра . Однако не все версии Mach являются микроядрами. Производные Mach составляют основу ядра операционной системы GNU Hurd и ядра Apple XNU , используемого в macOS , iOS , iPadOS , tvOS и watchOS .
Проект в Карнеги-Меллоне длился с 1985 по 1994 год [2] и завершился выпуском Mach 3.0, настоящего микроядра . Mach был разработан в качестве замены ядра BSD- версии Unix , поэтому на его основе не требовалось создавать новую операционную систему. Mach и его производные существуют в ряде коммерческих операционных систем. Все они включают в себя использование ядра операционной системы XNU, которое включает в себя более ранний немикроядерный Mach в качестве основного компонента. Система управления виртуальной памятью Mach также была принята в 4.4BSD разработчиками BSD из CSRG [ 3] и появляется в современных Unix-системах, производных от BSD, таких как FreeBSD .
Mach является логическим преемником ядра Accent Карнеги-Меллона . Ведущий разработчик проекта Mach Ричард Рашид работает в Microsoft с 1991 года; он основал исследовательское подразделение Microsoft . Другой из первоначальных разработчиков Mach, Ави Теванян, ранее до марта 2006 года был главой отдела программного обеспечения в NeXT , а затем директором по технологиям программного обеспечения в Apple Inc. [4] [2]
Разработчикам приходилось ездить на обед на велосипеде по грязным лужам дождливого Питтсбурга, и Теванян пошутил, что слово «навоз» может стать бэкронимом для их многопользовательского ( или многопроцессорного универсального ) коммуникационного ядра . Итальянский инженер CMU Дарио Джузе [5] позже спросил руководителя проекта Рика Рашида о нынешнем названии проекта и получил в ответ «MUCK», правда, не прописанное, а просто произнесенное: IPA: [mʌk] что он, согласно итальянскому алфавиту , писал как Мах. Рашиду настолько понравилось написание Джузе «Мах», что оно возобладало. [6] : 103
Ключевой концепцией исходной операционной системы Unix была идея канала . Канал представлял собой абстракцию , которая позволяла перемещать данные в виде неструктурированного потока байтов из программы в программу. Используя каналы, пользователи (или программисты) могут связывать вместе несколько программ для выполнения задач, поочередно передавая данные через несколько небольших программ. Это контрастировало с типичными операционными системами той эпохи, которые требовали одной большой программы, способной справиться со всей задачей, или, альтернативно, использовали файлы для передачи данных, что требовало больших ресурсов и отнимало много времени.
Каналы были построены на основе базовой системы ввода/вывода . Эта система, в свою очередь, была основана на модели, в которой водители должны были периодически «блокироваться», пока ждали завершения задач. Например, драйвер принтера может отправить строку текста на построчный принтер , а затем ничего не делать, пока принтер не завершит печать этой строки. В этом случае драйвер укажет, что он заблокирован, а операционная система разрешит запуск какой-либо другой программы до тех пор, пока принтер не сообщит, что он готов к получению дополнительных данных. В системе каналов ограниченным ресурсом была память, и когда одна программа заполняла память, назначенную каналу, она, естественно, блокировалась. Обычно это приводит к запуску потребляющей программы и повторному опорожнению канала. В отличие от файла, где весь файл должен быть прочитан или записан, прежде чем следующая программа сможет его использовать, в каналах перемещение данных между несколькими программами происходит поэтапно, без какого-либо вмешательства программиста.
Однако реализация каналов в буферах памяти вынудила копировать данные из программы в программу, а это трудоемкая и ресурсоемкая операция. Это сделало концепцию канала непригодной для задач, где требовалась быстрая обработка или малая задержка, например, в большинстве драйверов устройств . Вместо этого ядро операционной системы и большая часть основных функций были написаны в одной большой программе. Когда в операционную систему были добавлены новые функции, такие как создание компьютерных сетей , размер и сложность ядра также выросли.
Каналы Unix предлагали концептуальную систему, которую можно было использовать для создания сколь угодно сложных решений из небольших взаимодействующих программ. Эти небольшие программы было легче разрабатывать и поддерживать, и они имели четко определенные интерфейсы, которые упрощали программирование и отладку. Эти качества еще более ценны для драйверов устройств, для которых крайне важны малый размер и безошибочная работа. Было сильное желание смоделировать само ядро на той же основе небольших взаимодействующих программ.
Одной из первых систем, в которой использовалась конвейерная система, лежащая в основе операционной системы, было ядро Aleph, разработанное в Рочестерском университете . Это ввело концепцию портов , которые по сути были реализацией разделяемой памяти . В Aleph само ядро было сведено к обеспечению доступа к оборудованию, включая память и порты, в то время как обычные программы, использующие систему портов, реализовывали все поведение, от драйверов устройств до пользовательских программ. Эта концепция значительно уменьшила размер ядра и позволила пользователям экспериментировать с различными драйверами, просто загружая их и соединяя во время выполнения. Это значительно облегчило проблемы при разработке нового кода операционной системы, который в противном случае обычно требовал перезагрузки компьютера. Общая концепция небольшого ядра и внешних драйверов стала известна как микроядро.
Aleph был реализован на миникомпьютерах Data General Eclipse и был тесно с ними связан. Эта машина была далека от идеала, поскольку требовала копирования памяти между программами, что приводило к значительному снижению производительности. Это также было довольно дорого. Тем не менее, Алеф доказал, что базовая система работает, и продолжил демонстрировать кластеризацию компьютеров , копируя память через ранний интерфейс Ethernet .
Примерно в это же время на рынке появилось новое поколение центральных процессоров (ЦП), предлагающее 32-битное адресное пространство и (первоначально необязательно) поддержку блока управления памятью (MMU). MMU обрабатывал инструкции, необходимые для реализации системы виртуальной памяти , отслеживая, какие страницы памяти используются различными программами. Это предложило новое решение концепции порта, используя механизм копирования при записи, предоставляемый системой виртуальной памяти. Вместо копирования данных между программами все, что нужно было отправить, — это данные, необходимые для того, чтобы дать команду MMU предоставить доступ к одной и той же памяти. Эта система будет реализовывать систему межпроцессного взаимодействия с значительно более высокой производительностью.
Эта концепция была подхвачена в Карнеги-Меллоне, который адаптировал Aleph для рабочей станции PERQ и реализовал ее с использованием копирования при записи. Перенос прошел успешно, но полученное ядро Accent имело ограниченное практическое применение, поскольку на нем не запускалось существующее программное обеспечение. Более того, Accent был так же тесно привязан к PERQ, как Aleph к Eclipse.
Основным изменением между этими экспериментальными ядрами и Mach было решение создать версию существующего ядра 4.2BSD, повторно реализованную на основе концепции передачи сообщений Accent. Такое ядро будет двоично совместимо с существующим программным обеспечением BSD, что сделает систему сразу же полезной для повседневного использования, оставаясь при этом полезной экспериментальной платформой. Кроме того, новое ядро с самого начала будет спроектировано для поддержки нескольких процессорных архитектур, что позволит даже создавать гетерогенные кластеры. Чтобы запустить систему как можно быстрее, она будет реализована, начиная с существующего кода BSD и постепенно переопределяя его в виде программ на основе межпроцессного взаимодействия (IPC). Таким образом, Mach начинался как монолитная система, подобная существующим системам UNIX, и со временем все больше развивался в сторону концепции микроядра. [4]
Mach в основном представлял собой попытку создать четко определенный, легко переносимый Accent на базе UNIX. Результатом является краткий список общих понятий: [7] [8]
Мах разработал концепцию IPC Accent, но сделал систему гораздо более похожей на UNIX по своей природе, позволяя даже запускать программы UNIX с небольшими изменениями или без них. Для этого Мах ввел понятие порта , представляющего каждую конечную точку двустороннего IPC. Порты имели безопасность и права, как файлы в UNIX, что позволяло применять к ним очень UNIX-подобную модель защиты. Кроме того, Мах позволял любой программе обрабатывать привилегии, которые обычно предоставляются только операционной системе, чтобы позволить программам пользовательского пространства обрабатывать такие вещи, как взаимодействие с оборудованием.
В Mach, как и в UNIX, операционная система снова становится прежде всего набором утилит. Как и в UNIX, Mach сохраняет концепцию драйвера для работы с оборудованием. Поэтому все драйверы для существующего оборудования должны быть включены в микроядро. Другие архитектуры, основанные на уровне аппаратной абстракции или экзоядрах, могут перемещать драйверы из микроядра.
Основное отличие UNIX состоит в том, что вместо утилит, обрабатывающих файлы, они могут выполнять любую «задачу». Большая часть кода операционной системы была перенесена из ядра в пользовательское пространство, что привело к значительному уменьшению размера ядра и появлению термина « микроядро» . В отличие от традиционных систем, в системе Маха процесс или «задача» может состоять из нескольких потоков. Хотя это распространено в современных системах, Mach был первой системой, которая определяла задачи и потоки таким образом. Задача ядра свелась от роли операционной системы к поддержке «утилит» и планированию их доступа к оборудованию.
Наличие портов и использование IPC — пожалуй, самое принципиальное отличие Mach от традиционных ядер. В UNIX вызов ядра состоит из операции, называемой системным вызовом или ловушкой . Программа использует библиотеку для размещения данных в хорошо известном месте памяти, а затем вызывает ошибку — тип ошибки. При первом запуске системы ее ядро настроено на роль «обработчика» всех ошибок; таким образом, когда программа вызывает ошибку, ядро берет на себя управление, проверяет переданную ему информацию, а затем выполняет инструкции.
При Маха вместо этого для этой роли использовалась система IPC. Чтобы вызвать функциональные возможности системы, программа запрашивает у ядра доступ к порту, а затем использует систему IPC для отправки сообщений на этот порт. Хотя для отправки сообщения требуется системный вызов, точно так же, как запрос системных функций в других системах требует системного вызова, в системе Mach отправка сообщения — это практически все, что делает ядро; обработка фактического запроса будет зависеть от какой-либо другой программы.
Поддержка потоков и параллелизма улучшилась за счет передачи сообщений с помощью механизмов IPC, поскольку задачи теперь состояли из нескольких потоков кода, которые Mach мог заморозить и разморозить во время обработки сообщений. Это позволило распределить систему по нескольким процессорам, либо используя общую память напрямую, как в большинстве сообщений Маха, либо добавляя код для копирования сообщения на другой процессор, если это необходимо. В традиционном ядре это сложно реализовать; система должна быть уверена, что разные программы не пытаются писать в одну и ту же память с разных процессоров. Однако порты Маха, процесс доступа к памяти, делают это четко определенным и простым в реализации, и стали первоклассным гражданином в этой системе.
Первоначально у системы IPC были проблемы с производительностью, поэтому было разработано несколько стратегий, позволяющих минимизировать это влияние. Как и его предшественник, Accent, Mach использовал единый механизм общей памяти для физической передачи сообщения от одной программы к другой. Физическое копирование сообщения будет слишком медленным, поэтому Мах полагается на блок управления памятью машины (MMU), чтобы быстро сопоставить данные из одной программы в другую. Только если данные записаны, их необходимо физически скопировать. Этот процесс называется « копирование при записи ».
Сообщения также проверялись ядром на достоверность, чтобы избежать сбоя в работе одной из многих программ, составляющих систему, из-за неверных данных. Порты были намеренно смоделированы на основе концепций файловой системы UNIX. Это позволило пользователю находить порты, используя существующие концепции навигации по файловой системе, а также назначать права и разрешения так же, как и в файловой системе.
Развитие при такой системе было бы проще. Код, над которым ведется работа, не только существовал бы в традиционной программе, которую можно было бы построить с использованием существующих инструментов, но также можно было бы запускать, отлаживать и завершать работу с использованием тех же инструментов. В моноядре ошибка в новом коде приведет к выходу из строя всей машины и потребует перезагрузки, тогда как под Mach для этого потребуется только перезапустить программу. Кроме того, пользователь может настроить систему, включив или исключив любые необходимые ему функции. Поскольку операционная система представляла собой просто набор программ, они могли добавлять или удалять части, просто запуская или уничтожая их, как и любую другую программу.
Наконец, при Маха все эти функции были намеренно разработаны так, чтобы быть максимально нейтральными к платформе. Процитируем один текст о Маха:
Однако есть ряд недостатков. Относительно обыденный — непонятно, как найти порты. В UNIX эта проблема со временем была решена, поскольку программисты договорились о ряде «хорошо известных» мест в файловой системе для выполнения различных задач. Хотя тот же подход работал и для портов Маха, предполагалось, что под ним операционная система будет гораздо более гибкой: порты постоянно появляются и исчезают. Без какого-либо механизма поиска портов и сервисов, которые они представляют, большая часть этой гибкости будет потеряна.
Первоначально Mach размещался как дополнительный код, написанный непосредственно в существующем ядре 4.2BSD, что позволяло команде работать над системой задолго до ее завершения. Работа началась с уже функционирующей системы Accent IPC/port и перешла к другим ключевым частям ОС: задачам, потокам и виртуальной памяти. По мере того, как некоторые части были завершены, различные части системы BSD были переписаны для вызова Mach, и во время этого процесса также было сделано изменение на 4.3BSD.
К 1986 году система была завершена до такой степени, что ее можно было использовать самостоятельно на DEC VAX . Несмотря на то, что это не имело практической ценности, цель создания микроядра была реализована. Вскоре за этим последовали версии для ПК IBM RT и для рабочих станций на базе Sun Microsystems 68030 , что доказало портативность системы. К 1987 году в список вошли машины Encore Multimax и Sequent Balance , проверявшие способность Mach работать на многопроцессорных системах. В том же году был выпущен публичный выпуск 1, а в следующем году последовал выпуск 2.
На протяжении всего этого времени обещание создания «настоящего» микроядра еще не было реализовано. Эти ранние версии Mach включали в ядро большую часть 4.3BSD, систему, известную как POE Server, в результате чего ядро было фактически больше, чем UNIX, на котором оно было основано. Идея, однако, заключалась в том, чтобы перенести уровень UNIX из ядра в пространство пользователя, где с ним можно было бы легче работать и даже полностью заменить. К сожалению, производительность оказалась серьезной проблемой, и для решения этой проблемы был внесен ряд архитектурных изменений. Громоздкие проблемы лицензирования UNIX также беспокоили исследователей, поэтому эта ранняя попытка создать нелицензируемую UNIX-подобную системную среду продолжала находить применение даже в дальнейшем развитии Mach.
Получившийся в результате Mach 3 был выпущен в 1990 году и вызвал большой интерес. Небольшая команда создала Mach и портировала его на ряд платформ, включая сложные многопроцессорные системы, которые создавали серьезные проблемы для ядер старого типа. Это вызвало значительный интерес на коммерческом рынке, где ряд компаний рассматривали возможность смены аппаратных платформ. Если бы существующую систему можно было портировать для работы на Mach, казалось бы, было бы легко изменить платформу под ней.
Mach стал значительно популярнее, когда Фонд открытого программного обеспечения (OSF) объявил, что будет размещать будущие версии OSF/1 на скорости 2,5 Маха, а также исследовал возможность использования Mach 3. Скорость 2,5 Маха также была выбрана для системы NeXTSTEP и ряда коммерческих производителей мультипроцессоров. Mach 3 привел к ряду попыток портировать другие части операционных систем для микроядра, включая IBM Workplace OS , а также несколько усилий Apple по созданию кроссплатформенной версии классической Mac OS . [10] Поддержка запуска приложений DOS в среде Mach 3.0 была продемонстрирована исследователями в продолжение более ранней работы с классической Mac OS и MultiFinder под Mach 2.5. [11]
Mach изначально задумывался как замена классической монолитной UNIX и по этой причине содержал множество UNIX-подобных идей. Например, Мах использовал систему разрешений и безопасности, созданную по образцу файловой системы UNIX. Поскольку ядро имело привилегии (работало в пространстве ядра ) над другими серверами ОС и программным обеспечением, неисправные или вредоносные программы могли отправлять ему команды, которые могли бы нанести ущерб системе, и по этой причине ядро проверяло каждое сообщение на достоверность. . Кроме того, большая часть функций операционной системы должна была быть расположена в программах пользовательского пространства, поэтому это означало, что ядру должен был быть какой-то способ предоставить этим программам дополнительные привилегии, например, для прямого доступа к оборудованию.
Некоторые из наиболее эзотерических функций Маха также были основаны на том же механизме IPC. Например, Mach мог легко поддерживать многопроцессорные машины. В традиционном ядре необходимо провести обширную работу, чтобы сделать его реентерабельным или прерываемым , поскольку программы, работающие на разных процессорах, могут одновременно обращаться к ядру. Под Mach биты операционной системы изолированы на серверах, которые способны работать, как и любая другая программа, на любом процессоре. Хотя теоретически ядро Mach также должно быть реентерабельным, на практике это не проблема, поскольку время отклика настолько быстрое, что оно может просто ждать и обслуживать запросы по очереди. Mach также включал в себя сервер, который мог пересылать сообщения не только между программами, но даже по сети, что было областью интенсивного развития в конце 1980-х — начале 1990-х годов.
К сожалению, использование IPC практически для всех задач оказало серьезное влияние на производительность. Тесты оборудования 1997 года показали, что односерверные реализации UNIX на базе Mach 3.0 были примерно на 50% медленнее, чем родная UNIX. [12] [13]
Изучение точной природы проблем с производительностью выявило ряд интересных фактов. Во-первых, проблема заключалась не в самом IPC: существовали некоторые накладные расходы, связанные с отображением памяти, необходимым для его поддержки, но это добавляло лишь небольшое количество времени к выполнению вызова. Остальное, 80% времени, было потрачено на дополнительные задачи, которые ядро выполняло над сообщениями. Главной среди них была проверка прав порта и достоверность сообщений. В тестах на 486 DX-50 стандартный системный вызов UNIX занимал в среднем 21 мкс , тогда как эквивалентная операция с Mach IPC занимала в среднем 114 мкс. Только 18 мкс из них были связаны с аппаратным обеспечением; остальное было ядром Маха, выполняющим различные процедуры для обработки сообщения. [14] Учитывая системный вызов, который ничего не делает, полный цикл туда-обратно в BSD потребует около 40 мкс, тогда как в системе Mach в пользовательском пространстве это займет чуть менее 500 мкс.
Когда Mach впервые серьезно использовался в версиях 2.x, производительность была ниже, чем у традиционных монолитных операционных систем, возможно, на целых 25%. [1] Однако эта стоимость не вызывала особого беспокойства, поскольку система также предлагала поддержку нескольких процессоров и легкую переносимость. Многие считали, что это ожидаемая и приемлемая цена. Когда Mach 3 попытался переместить большую часть операционной системы в пользовательское пространство, накладные расходы стали еще выше: тесты между Mach и Ultrix на MIPS R3000 показали падение производительности на 67% при некоторых рабочих нагрузках. [15]
Например, получение системного времени включает вызов IPC к серверу пользовательского пространства, поддерживающему системные часы . Вызывающий сначала попадает в ядро, вызывая переключение контекста и отображение памяти. Затем ядро проверяет, есть ли у вызывающего абонента необходимые права доступа и достоверность сообщения. Если это так, существует еще одно переключение контекста и отображение памяти для завершения вызова сервера пользовательского пространства. Затем процесс необходимо повторить для возврата результатов, что в сумме составит четыре переключения контекста и сопоставления памяти, а также две проверки сообщений. Эти накладные расходы быстро усугубляются более сложными сервисами, в которых пути кода часто проходят через множество серверов.
Это был не единственный источник проблем с производительностью. Другой был сосредоточен на проблемах правильного обращения с памятью, когда физическая память заканчивалась и приходилось выполнять подкачку. В традиционных монолитных операционных системах авторы имели непосредственный опыт определения того, какие части ядра вызывают другие, что позволяло им точно настраивать свой пейджер, чтобы избежать выгрузки кода, который собирался использоваться. При Маха это было невозможно, потому что ядро понятия не имело, из чего состоит операционная система. Вместо этого им пришлось использовать единое универсальное решение, что усугубляло проблемы с производительностью. Mach 3 попыталась решить эту проблему, предоставив простой пейджер, полагаясь на пейджеры в пользовательском пространстве для лучшей специализации. Но это, как оказалось, имело небольшой эффект. На практике все преимущества, которые он имел, были сведены на нет дорогостоящими затратами IPC, необходимыми для его вызова.
Другие проблемы с производительностью были связаны с поддержкой Mach многопроцессорных систем. С середины 1980-х до начала 1990-х производительность обычных процессоров росла примерно на 60% в год, но скорость доступа к памяти росла всего на 7% в год. Это означало, что стоимость доступа к памяти за этот период значительно выросла, а поскольку Mach был основан на сопоставлении памяти между программами, любой «промах в кэше» замедлял вызовы IPC.
Накладные расходы IPC являются серьезной проблемой для систем со скоростью 3 Маха. Однако концепция многосерверной операционной системы по-прежнему перспективна, хотя и требует некоторых исследований. Разработчикам следует быть осторожными и изолировать код в модули, которые не вызываются с сервера на сервер. Например, большая часть сетевого кода будет размещена на одном сервере, тем самым минимизируя IPC для обычных сетевых задач.
Вместо этого большинство разработчиков придерживались первоначальной концепции POE, заключающейся в том, что один большой сервер обеспечивает функциональность операционной системы. [16] Чтобы облегчить разработку, они позволили серверу операционной системы работать либо в пространстве пользователя, либо в пространстве ядра. Это позволило им развиваться в пользовательском пространстве и воспользоваться всеми преимуществами исходной идеи Маха, а затем переместить отлаженный сервер в пространство ядра, чтобы добиться большей производительности. С тех пор было создано несколько операционных систем с использованием этого метода, известного как совместное размещение , в том числе Lites , MkLinux , OSF/1 и NeXTSTEP/OPENSTEP/macOS. Микроядро Chorus сделало это особенностью базовой системы, позволяя поднимать серверы в пространство ядра с помощью встроенных механизмов.
Mach 4 попыталась решить эти проблемы, на этот раз с помощью более радикального набора обновлений. В частности, было обнаружено, что программный код обычно не доступен для записи, поэтому потенциальные попадания из-за копирования при записи были редки. Таким образом, имело смысл не отображать память между программами для IPC, а вместо этого перенести используемый программный код в локальное пространство программы. Это привело к появлению концепции «челноков», и казалось, что производительность улучшилась, но разработчики продолжили работу над системой в полупригодном для использования состоянии. В Mach 4 также появились встроенные примитивы совместного размещения, что сделало их частью самого ядра.
К середине 1990-х годов работа над микроядерными системами в значительной степени застопорилась, хотя рынок в целом считал , что к 1990-м годам все современные операционные системы будут основаны на микроядре. Основными оставшимися широко распространенными вариантами использования ядра Mach являются macOS от Apple и ее родственная iOS, которые работают на базе сильно модифицированного гибридного ядра Mach Open Software Foundation (OSFMK 7.3) под названием « XNU » [17] , также используемого в OSF/1. [10] В XNU файловые системы, сетевые стеки, а также функции управления процессами и памятью реализованы в ядре; файловая система, сеть и некоторые функции управления процессами и памятью вызываются из пользовательского режима посредством обычных системных вызовов , а не посредством передачи сообщений; [18] [19] Сообщения Маха XNU используются для связи между процессами пользовательского режима, а также для некоторых запросов от кода пользовательского режима к ядру и от ядра к серверам пользовательского режима.
Дальнейший анализ показал, что проблема с производительностью IPC не так очевидна, как казалось. Напомним, что односторонний системный вызов занимал 20 мкс в BSD [3] и 114 мкс на Mach, работающем в той же системе. [2] Из 114 11 произошли из-за переключения контекста, идентичного BSD. [13] Еще 18 были использованы MMU для отображения сообщения между пользовательским пространством и пространством ядра. [3] В сумме это составляет всего 29 мкс, что дольше, чем традиционный системный вызов, но ненамного.
Остальное, большая часть реальной проблемы, было связано с тем, что ядро выполняло такие задачи, как проверка сообщения на наличие прав доступа к порту. [6] Хотя может показаться, что это важная проблема безопасности, на самом деле это имеет смысл только в UNIX-подобных системах. Например, однопользовательская операционная система, работающая на мобильном телефоне или роботе , может не нуждаться ни в одной из этих функций, и это именно тот тип системы, в котором операционная система Маха «выбирай и выбирай» будет наиболее ценной. Точно так же Mach вызывал проблемы, когда операционная система перемещала память — еще одна задача, которая действительно имеет смысл только в том случае, если система имеет более одного адресного пространства. DOS и ранние версии Mac OS имели единое большое адресное пространство, совместно используемое всеми программами, поэтому в этих системах отображение не давало никаких преимуществ.
Эти реализации привели к созданию серии микроядер второго поколения, которые еще больше снизили сложность системы и разместили почти все функциональные возможности в пользовательском пространстве. Например, ядро L4 (версия 2) включает всего семь системных вызовов и использует 12 КБ памяти, [3] тогда как Mach 3 включает около 140 функций и использует около 330 КБ памяти. [3] Вызовы IPC на уровне L4 на 486DX-50 занимают всего 5 мкс, [19] быстрее, чем системный вызов UNIX в той же системе, и более чем в 20 раз быстрее, чем Mach. Конечно, это игнорирует тот факт, что L4 не занимается разрешением или безопасностью; но, оставив это на усмотрение программ пользовательского пространства, они могут выбирать столько накладных расходов, сколько им необходимо.
Потенциальный прирост производительности L4 сдерживается тем фактом, что приложениям пользовательского пространства часто приходится предоставлять многие функции, ранее поддерживаемые ядром. Чтобы проверить сквозную производительность, MkLinux в совместном режиме сравнивался с портом L4, работающим в пользовательском пространстве. L4 добавил около 5–10% накладных расходов [13] по сравнению с 29% у Mach. [13]
Ниже приводится список ядер операционных систем, производных от Mach, и операционных систем с ядрами, производными от Mach: