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