ماخ (نواة)

ركب المطورون دراجاتهم الهوائية لتناول الغداء عبر برك الطين في بيتسبرغ الممطرة، ومازح تيفانيان قائلاً إن كلمة "muck" (وحل) يمكن أن تشكل اختصارًا عكسيًا لنواة الاتصال متعددة المستخدمين (أو متعددة المعالجات العالمية). سأل المهندس الإيطالي داريو جيوز ^{[ 5 ]} قائد المشروع ريك رشيد عن الاسم الحالي للمشروع، فتلقى إجابة "MUCK" (وإن لم تُكتب الكلمة كاملة، بل نُطقت فقط /mʌk / ) . ووفقًا للأبجدية الإيطالية ، كتب رشيد "Mach" (ماخ). أعجب رشيد تهجئة جيوز "Mach" لدرجة أنها اعتُمدت. ^{[ 6 ] : 103}

يُعدّ مفهوم الأنابيب أحد المفاهيم الأساسية في نظام التشغيل يونكس الأصلي . فالأنابيب عبارة عن تجريد يسمح بنقل البيانات كتدفق غير منظم من البايتات بين البرامج. وباستخدام الأنابيب، يستطيع المستخدمون ربط برامج متعددة لإنجاز مهام محددة، وذلك بتمرير البيانات عبر عدة برامج صغيرة متتالية. وهذا يختلف عن أنظمة التشغيل التقليدية في ذلك الوقت، التي كانت تتطلب برنامجًا واحدًا كبيرًا قادرًا على إنجاز المهمة بأكملها، أو كانت تستخدم الملفات لنقل البيانات، وهو ما كان يستهلك موارد النظام ويستغرق وقتًا طويلاً.

بُنيت الأنابيب على نظام الإدخال/الإخراج الأساسي . ويعتمد هذا النظام بدوره على نموذج يُتوقع فيه من برامج التشغيل "التوقف" دوريًا أثناء انتظارها اكتمال المهام. على سبيل المثال، قد يُرسل برنامج تشغيل طابعة سطرًا نصيًا إلى طابعة خطية ، ثم لا يكون لديه ما يفعله حتى تنتهي الطابعة من طباعة ذلك السطر. في هذه الحالة، يُشير برنامج التشغيل إلى أنه متوقف، ويسمح نظام التشغيل لبرنامج آخر بالعمل حتى تُشير الطابعة إلى استعدادها لمزيد من البيانات. في نظام الأنابيب، كان المورد المحدود هو الذاكرة، وعندما يملأ أحد البرامج الذاكرة المُخصصة للأنبوب، فإنه سيتوقف تلقائيًا. عادةً ما يؤدي هذا إلى تشغيل البرنامج المُستهلك، مما يُفرغ الأنبوب مرة أخرى. على عكس الملف، حيث يجب قراءة الملف بالكامل أو الكتابة إليه قبل أن يتمكن البرنامج التالي من استخدامه، جعلت الأنابيب نقل البيانات بين برامج متعددة يتم بشكل تدريجي دون أي تدخل من المبرمج.

أدى استخدام الأنابيب في مخازن الذاكرة إلى إجبار النظام على نسخ البيانات من برنامج لآخر، وهي عملية تستغرق وقتًا طويلاً وتستهلك موارد كثيرة. هذا جعل مفهوم الأنابيب غير مناسب للمهام التي تتطلب سرعة استجابة عالية أو زمن استجابة منخفض، كما هو الحال في معظم برامج تشغيل الأجهزة . ولذلك، كُتبت نواة نظام التشغيل ومعظم وظائفه الأساسية في برنامج واحد كبير. وعندما أُضيفت وظائف جديدة، مثل شبكات الحاسوب ، إلى نظام التشغيل، ازداد حجم النواة وتعقيدها أيضًا.

وفرت أنابيب يونكس نظامًا مفاهيميًا يُمكن استخدامه لبناء حلول بالغة التعقيد من خلال برامج صغيرة متعاونة. تميزت هذه البرامج الأصغر حجمًا بسهولة تطويرها وصيانتها، فضلًا عن واجهاتها الواضحة التي سهّلت البرمجة وتصحيح الأخطاء. وتزداد أهمية هذه الميزات في برامج تشغيل الأجهزة، حيث يُعدّ صغر الحجم والأداء الخالي من الأخطاء أمرًا بالغ الأهمية. وقد برزت رغبة قوية في تصميم نواة النظام على نفس أساس البرامج الصغيرة المتعاونة.

كان نظام Aleph، الذي طُوّر في جامعة روتشستر ، من أوائل الأنظمة التي استخدمت نظامًا شبيهًا بالأنابيب لدعم نظام التشغيل . وقد قدّم هذا النظام مفهوم المنافذ، التي كانت في جوهرها تطبيقًا للذاكرة المشتركة . في Aleph، اقتصر دور النواة على توفير الوصول إلى المكونات المادية، بما في ذلك الذاكرة والمنافذ، بينما تولّت البرامج التقليدية التي تستخدم نظام المنافذ تنفيذ جميع الوظائف، بدءًا من برامج تشغيل الأجهزة وصولًا إلى برامج المستخدم. قلّل هذا المفهوم حجم النواة بشكل كبير، وسمح للمستخدمين بتجربة برامج تشغيل مختلفة ببساطة عن طريق تحميلها وربطها معًا أثناء التشغيل. وقد سهّل هذا الأمر بشكل كبير عملية تطوير أكواد جديدة لنظام التشغيل، والتي كانت تتطلب في السابق إعادة تشغيل الجهاز. عُرف المفهوم العام للنواة الصغيرة وبرامج التشغيل الخارجية باسم النواة المصغّرة.

تم تطبيق نظام أليف على حواسيب إكليبس المصغرة من شركة داتا جنرال، وكان مرتبطًا بها ارتباطًا وثيقًا. لم يكن هذا الجهاز مثاليًا، إذ كان يتطلب نسخ الذاكرة بين البرامج، مما أدى إلى زيادة ملحوظة في استهلاك موارد النظام. كما كان مكلفًا للغاية. مع ذلك، أثبت أليف سلامة النظام الأساسي، وواصل مسيرته ليُظهر إمكانية تجميع الحواسيب عن طريق نسخ الذاكرة عبر واجهة إيثرنت بدائية .

في ذلك الوقت تقريبًا، ظهر جيل جديد من المعالجات المركزية (CPUs) في الأسواق، مزودًا بمساحة عناوين 32 بت ودعم (اختياري في البداية) لوحدة إدارة الذاكرة (MMU). تولت وحدة إدارة الذاكرة معالجة التعليمات اللازمة لتنفيذ نظام الذاكرة الافتراضية من خلال تتبع صفحات الذاكرة المستخدمة من قِبل البرامج المختلفة. وقدّم هذا حلًا جديدًا لمفهوم المنافذ، باستخدام آلية النسخ عند الكتابة (COW) التي يوفرها نظام الذاكرة الافتراضية. فبدلًا من نسخ البيانات بين البرامج، كان المطلوب فقط توجيه وحدة إدارة الذاكرة لتوفير الوصول إلى نفس الذاكرة. وقد ساهم هذا النظام في تنفيذ نظام الاتصالات بين العمليات (IPC) بأداء أعلى بكثير.

تم تبني هذا المفهوم في جامعة كارنيجي ميلون، حيث قاموا بتكييف نظام Aleph لمحطة عمل PERQ ونفذوه باستخدام تقنية النسخ عند الكتابة. نجحت عملية النقل، لكن نواة Accent الناتجة كانت محدودة الفائدة العملية لعدم قدرتها على تشغيل البرامج الموجودة. علاوة على ذلك، كان نظام Accent مرتبطًا ارتباطًا وثيقًا بنظام PERQ تمامًا كما كان نظام Aleph مرتبطًا بنظام Eclipse.

كان التغيير الرئيسي بين هذه النوى التجريبية ونظام Mach هو قرار إعادة تنفيذ نسخة من نواة 4.2BSD الحالية باستخدام مفاهيم تمرير الرسائل في Accent. ستكون هذه النواة متوافقة ثنائيًا مع برامج BSD الحالية ، مما يجعل النظام متاحًا للاستخدام اليومي فورًا مع الحفاظ على كونه منصة تجريبية مفيدة. بالإضافة إلى ذلك، صُممت النواة الجديدة منذ البداية لدعم بنى معالجات متعددة، بل وتسمح بإنشاء مجموعات غير متجانسة. ولتشغيل النظام بأسرع وقت ممكن، سيتم تنفيذه بدءًا من كود BSD الحالي، ثم إعادة تنفيذه تدريجيًا كبرامج تعتمد على الاتصال بين العمليات (IPC). وهكذا، سيبدأ Mach كنظام متكامل مشابه لأنظمة UNIX الحالية، ويتطور تدريجيًا نحو مفهوم النواة المصغرة. ^{[ 4 ]}

بدأ مشروع Mach في الأساس كجهد لإنتاج لغة برمجة Accent واضحة المعالم، تعتمد على نظام UNIX، وقابلة للنقل بدرجة عالية. وكانت النتيجة قائمة مختصرة من المفاهيم العامة: ^{[ 7 ] [ 8 ]}

• المهمة هي مجموعة من موارد النظام التي تنتج " خيوطًا" لتشغيلها
• الخيط هو وحدة تنفيذ واحدة، موجودة ضمن سياق مهمة ما، وتشارك موارد تلك المهمة .
• المنفذ عبارة عن قائمة انتظار رسائل محمية للاتصال بين المهام؛ وتمتلك المهام حقوق الإرسال والاستقبال (الأذونات) لكل منفذ .
• "messages" are collections of typed data, they can only be sent to ports—not specifically tasks or threads

Mach developed on Accent's IPC concepts, but made the system much more UNIX-like in nature, making it possible to run UNIX programs with little or no modification. To do this, Mach introduced the port, representing each endpoint of a two-way IPC. Ports had a concept of permissions like files under UNIX, permitting a very UNIX-like model of protection to be applied to them. Additionally, Mach allowed any program to handle privileges that would normally be given to the operating system only, in order to permit user space programs to handle things such as controlling hardware.

Under Mach, and like UNIX, the operating system again becomes primarily a collection of utilities. As with UNIX, Mach keeps the concept of a driver for handling the hardware. Therefore, all the drivers for the present hardware have to be included in the microkernel. Other architectures based on hardware abstraction layer or exokernels could move the drivers out of the microkernel.

The main difference with UNIX is that instead of utilities handling files, they can handle any "task". More operating system code was moved out of the kernel and into user space, resulting in a much smaller kernel and the rise of the term microkernel. Unlike traditional systems, under Mach a process, or "task", can consist of a number of threads. While this is common in modern systems, Mach was the first system to define tasks and threads in this way. The kernel's job was reduced from essentially being the operating system to running the "utilities" and providing them access to the hardware.

The existence of ports and the use of IPC is perhaps the most fundamental difference between Mach and traditional kernels. Under UNIX, calling the kernel consists of an operation named a system call or trap. The program uses a library to place data in a well known location in memory and then causes a fault, a type of error. When a system is first started, its kernel is set up to be the "handler" of all faults; thus, when a program causes a fault, the kernel takes over, examines the information passed to it, then carries out the instructions.

Under Mach, the IPC system was used for this role instead. To call system functionality, a program would ask the kernel for access to a port, then use the IPC system to send messages to that port. Although sending a message requires a system call, just as a request for system functionality on other systems requires a system call, under Mach sending the message is pretty much all the kernel does; handling the actual request would be up to some other program.

Thread and concurrency support benefited by message passing with IPC mechanisms because tasks now consist of multiple code threads that Mach could freeze and unfreeze during message handling. This permits the system to be distributed over multiple processors, either by using shared memory directly as in most Mach messages, or by adding code to copy the message to another processor if needed. In a traditional kernel this is difficult to implement; the system has to be sure that different programs do not try to write to the same region of memory from different processors. Using Mach ports makes this well defined and easy to implement, however, so Mach ports were made first-class citizens in that system.

The IPC system initially had performance problems, so a few strategies were developed to improve performance. Like its predecessor, Accent, Mach used a single shared-memory mechanism for physically passing the message from one program to another. Physically copying the message would be too slow, so Mach relies on the machine's memory management unit (MMU) to quickly map the data from one program to another. Only if the data is written to would it have to be physically copied, a process called "copy-on-write".

Messages were also checked for validity by the kernel, to avoid bad data crashing one of the many programs making up the system. Ports were deliberately modeled on the UNIX file system concepts. This permits the user to find ports using existing file system navigation concepts, as well as assigning rights and permissions as they would on the file system.

Development under such a system would be easier. Not only would the code being worked on exist in a traditional program that could be built using existing tools, it could also be started, debugged and killed off using the same tools. With a monokernel a bug in new code would take down the entire machine and require a reboot, whereas under Mach this would require only that the program be restarted. Additionally the user could tailor the system to include, or exclude, whatever features they required. Since the operating system was simply a collection of programs, they could add or remove parts by simply running or killing them as they would any other program.

Finally, under Mach, all of these features were deliberately designed to be extremely platform neutral. To quote one text on Mach:

على عكس نظام يونكس، الذي طُوّر دون مراعاة المعالجة المتعددة، يدمج نظام ماش دعم المعالجة المتعددة بشكل كامل. كما يتميز دعمه للمعالجة المتعددة بمرونة فائقة، بدءًا من أنظمة الذاكرة المشتركة وصولًا إلى الأنظمة التي لا تتشارك فيها المعالجات الذاكرة. صُمم ماش ليعمل على أنظمة حاسوبية تتراوح بين معالج واحد وآلاف المعالجات. إضافةً إلى ذلك، يُمكن نقل ماش بسهولة إلى العديد من بنى الحاسوب المتنوعة. يتمثل أحد الأهداف الرئيسية لماش في أن يكون نظامًا موزعًا قادرًا على العمل على أجهزة غير متجانسة. ^{[ 9 ]}

مع ذلك، توجد عدة عيوب. أحدها، وهو عيب بسيط نسبيًا، هو عدم وضوح كيفية العثور على المنافذ. في نظام يونكس، حُلّت هذه المشكلة تدريجيًا، حيث اتفق المبرمجون على عدد من المواقع "المعروفة" في نظام الملفات لأداء وظائف مختلفة. ورغم أن هذا النهج نفسه نجح مع منافذ نظام ماخ، إلا أنه في نظام ماخ، كان يُفترض أن يكون النظام أكثر مرونة، حيث تظهر المنافذ وتختفي باستمرار. وبدون آلية ما للعثور على المنافذ والخدمات التي تمثلها، ستُفقد الكثير من هذه المرونة.

في البداية، تم استضافة Mach كشفرة إضافية مكتوبة مباشرةً في نواة 4.2BSD الحالية، مما أتاح للفريق العمل على النظام قبل اكتماله بفترة طويلة. بدأ العمل بنظام Accent IPC/port الذي كان يعمل بالفعل، ثم انتقل إلى الأجزاء الرئيسية الأخرى من نظام التشغيل: المهام، والخيوط، والذاكرة الافتراضية. مع اكتمال أجزاء من النظام، أُعيدت كتابة أجزاء مختلفة من نظام BSD لاستدعاء Mach، كما أُجري تغيير على 4.3BSD خلال هذه العملية.

بحلول عام ١٩٨٦، اكتمل النظام لدرجة أنه أصبح قادرًا على العمل بشكل مستقل على جهاز DEC VAX . ورغم قلة الفائدة العملية التي حققها، فقد تحقق هدف إنشاء نواة مصغرة. وسرعان ما تبع ذلك إصدارات على جهاز IBM RT PC ومحطات عمل Sun Microsystems 68030 ، مما أثبت قابلية النظام للتنقل. وبحلول عام ١٩٨٧، شملت القائمة أجهزة Encore Multimax و Sequent Balance ، لاختبار قدرة Mach على العمل على أنظمة متعددة المعالجات. وصدر الإصدار الأول للجمهور في ذلك العام، وتبعه الإصدار الثاني في العام التالي.

خلال هذه الفترة، لم يتحقق وعد النواة المصغرة "الحقيقية". تضمنت الإصدارات الأولى من Mach معظم مكونات 4.3BSD في النواة، وهو نظام يُعرف باسم خادم POE، مما أدى إلى نواة أكبر حجمًا من نظام UNIX الذي بُنيت عليه. مع ذلك، كانت الفكرة هي نقل طبقة UNIX من النواة إلى مساحة المستخدم، حيث يسهل العمل عليها، بل واستبدالها بالكامل. لسوء الحظ، أثبت الأداء أنه مشكلة رئيسية، وأُجريت عدة تغييرات معمارية لحل هذه المشكلة. كما عانى الباحثون من مشاكل ترخيص UNIX المعقدة، لذا استمر استخدام هذا الجهد المبكر لتوفير بيئة نظام شبيهة بـ UNIX بدون ترخيص، حتى مع استمرار تطوير Mach.

أُصدر نظام التشغيل Mach 3 في عام 1990، وأثار اهتمامًا واسعًا. قام فريق صغير بتطوير Mach ونقله إلى عدد من المنصات، بما في ذلك أنظمة المعالجات المتعددة المعقدة التي كانت تُسبب مشاكل خطيرة لأنظمة التشغيل القديمة. وقد أثار هذا اهتمامًا كبيرًا في السوق التجارية، حيث كانت العديد من الشركات تُفكر في تغيير منصات الأجهزة. إذا أمكن نقل النظام الحالي ليعمل على Mach، فسيسهل حينها تغيير المنصة الأساسية.

حظي نظام التشغيل Mach باهتمام كبير عندما أعلنت مؤسسة البرمجيات المفتوحة (OSF) أنها ستستضيف الإصدارات المستقبلية من OSF/1 على Mach 2.5، وأنها تدرس أيضًا Mach 3. كما تم اختيار Mach 2.5 لنظام NeXTSTEP وعدد من موردي المعالجات المتعددة التجارية. أدى Mach 3 إلى بذل جهود عديدة لنقل أجزاء من أنظمة تشغيل أخرى إلى النواة المصغرة، بما في ذلك نظام التشغيل Workplace OS من IBM ، والعديد من الجهود التي بذلتها Apple لبناء نسخة متعددة المنصات من نظام التشغيل Mac OS الكلاسيكي . ^{[ 10 ]} وقد أثبت الباحثون دعم تشغيل تطبيقات DOS في بيئة Mach 3.0، استكمالًا لأعمال سابقة لتشغيل نظام التشغيل Mac OS الكلاسيكي و MultiFinder على Mach 2.5. ^{[ 11 ]} درس مشروع بحثي في ​​شركة Digital Equipment Corporation جدوى استضافة OpenVMS على نواة Mach 3، وأنشأ نموذجًا أوليًا باستخدام مجموعة فرعية من ميزات VMS. ^{[ 12 ]}

كان الهدف الأصلي من نظام التشغيل Mach هو استبدال نظام UNIX التقليدي المتكامل، ولذلك احتوى على العديد من الأفكار المشابهة لنظام UNIX. على سبيل المثال، وفّر Mach نظام أذونات وأمان مشابهًا لنظام ملفات UNIX. ولأن النواة كانت تتمتع بصلاحيات مميزة (تعمل في مساحة النواة ) على خوادم وبرامج أنظمة التشغيل الأخرى، كان من الممكن للبرامج المعيبة أو الخبيثة إرسال أوامر إليها تُلحق الضرر بالنظام، ولذلك كانت النواة تتحقق من صحة كل رسالة. بالإضافة إلى ذلك، كان من المقرر أن توجد معظم وظائف نظام التشغيل في برامج مساحة المستخدم، مما يعني ضرورة وجود طريقة ما تُمكّن النواة من منح هذه البرامج صلاحيات إضافية، مثل الوصول المباشر إلى مكونات الجهاز.

استندت بعض ميزات نظام التشغيل Mach الأكثر تخصصًا إلى آلية الاتصال بين العمليات (IPC) نفسها. فعلى سبيل المثال، كان Mach قادرًا على دعم الأجهزة متعددة المعالجات بسهولة. في النواة التقليدية، يتطلب الأمر جهدًا كبيرًا لجعلها قابلة لإعادة الدخول أو المقاطعة ، حيث يمكن للبرامج التي تعمل على معالجات مختلفة استدعاء النواة في الوقت نفسه. أما في Mach، فتُعزل أجزاء نظام التشغيل في خوادم، قادرة على العمل، كأي برنامج آخر، على أي معالج. ورغم أن نواة Mach نظريًا يجب أن تكون قابلة لإعادة الدخول، إلا أن هذا لا يمثل مشكلة عمليًا نظرًا لسرعة استجابتها الفائقة التي تسمح لها بالانتظار وتلبية الطلبات تباعًا. كما تضمن Mach خادمًا قادرًا على إعادة توجيه الرسائل ليس فقط بين البرامج، بل عبر الشبكة أيضًا، وهو مجال شهد تطورًا مكثفًا في أواخر الثمانينيات وأوائل التسعينيات.

لسوء الحظ، تبيّن أن استخدام بروتوكول الاتصال بين العمليات (IPC) في جميع المهام تقريبًا يؤثر سلبًا على الأداء. فقد أظهرت الاختبارات المعيارية على أجهزة عام 1997 أن تطبيقات نظام يونكس أحادية الخادم المبنية على Mach 3.0 كانت أبطأ بنحو 50% من نظام يونكس الأصلي. ^{[ 13 ] [ 14 ]}

كشفت دراسة طبيعة مشاكل الأداء عن عدد من الحقائق المثيرة للاهتمام. إحداها أن الاتصال بين العمليات (IPC) لم يكن هو المشكلة، إذ كان هناك بعض العبء الإضافي المرتبط بتخطيط الذاكرة اللازم لدعمه، لكن هذا لم يُضف سوى وقت ضئيل لإجراء الاستدعاء. أما النسبة المتبقية، 80% من الوقت المُستغرق، فكانت ناتجة عن مهام إضافية كان يُنفذها نظام التشغيل على الرسائل. وكان من أهم هذه المهام التحقق من حقوق المنافذ وصحة الرسائل. في اختبارات الأداء على معالج 486 DX-50، استغرق استدعاء نظام UNIX القياسي 21 ميكروثانية في المتوسط ​​لإكماله، بينما استغرقت العملية المكافئة باستخدام Mach IPC 114 ميكروثانية في المتوسط. 18 ميكروثانية فقط من هذا الوقت كانت متعلقة بالأجهزة، أما الباقي فكان بسبب تشغيل نظام Mach لروتينات مختلفة على الرسالة. ^{[ 15 ]} عند إجراء استدعاء نظام لا يقوم بأي شيء، فإن دورة كاملة ذهابًا وإيابًا في نظام BSD ستستغرق حوالي 40 ميكروثانية، بينما في نظام Mach في مساحة المستخدم ستستغرق أقل من 500 ميكروثانية.

عندما بدأ استخدام Mach بشكل جدي في الإصدارات 2.x، كان الأداء أبطأ من أنظمة التشغيل التقليدية أحادية البنية، ربما بنسبة تصل إلى 25%. ^{[ 1 ]} مع ذلك، لم يُعتبر هذا الأمر مقلقًا بشكل خاص، نظرًا لأن النظام كان يدعم أيضًا المعالجات المتعددة ويسهل نقله. ورأى الكثيرون أن هذه تكلفة متوقعة ومقبولة. عندما حاول Mach 3 نقل معظم نظام التشغيل إلى مساحة المستخدم، ازداد العبء بشكل أكبر: أظهرت المقارنات المعيارية بين Mach و Ultrix على معالج MIPS R3000 انخفاضًا في الأداء يصل إلى 67% في بعض أحمال العمل. ^{[ 16 ]}

على سبيل المثال، يتطلب الحصول على وقت النظام إجراء اتصال بين العمليات (IPC) مع خادم مساحة المستخدم المسؤول عن ساعة النظام . يقوم المستدعي أولاً بالتواصل مع نواة النظام، مما يؤدي إلى تبديل السياق وتعيين الذاكرة. ثم تتحقق النواة من امتلاك المستدعي لصلاحيات الوصول المطلوبة ومن صحة الرسالة. إذا كانت الرسالة صحيحة، يتم إجراء تبديل سياق آخر وتعيين ذاكرة لإتمام الاتصال بخادم مساحة المستخدم. يجب تكرار هذه العملية لإعادة النتائج، ليصل المجموع إلى أربعة عمليات تبديل سياق وتعيين ذاكرة، بالإضافة إلى عمليتي تحقق من الرسالة. يتضاعف هذا العبء بسرعة مع الخدمات الأكثر تعقيدًا، حيث غالبًا ما تمر مسارات التعليمات البرمجية عبر العديد من الخوادم.

لم يكن هذا المصدر الوحيد لمشاكل الأداء. تمحور مصدر آخر حول صعوبة إدارة الذاكرة بكفاءة عند انخفاض الذاكرة الفعلية واضطرار النظام إلى استخدام الترحيل. في أنظمة التشغيل التقليدية المتجانسة، كان لدى مطوري النظام خبرة مباشرة في تحديد أجزاء النواة التي تستدعي أجزاءً أخرى، مما سمح لهم بضبط نظام الترحيل بدقة لتجنب ترحيل التعليمات البرمجية التي ستُستخدم قريبًا. في نظام Mach، لم يكن هذا ممكنًا لأن النواة لم تكن على دراية حقيقية بمكونات نظام التشغيل. لذا، اضطروا إلى استخدام حل واحد شامل، مما زاد من مشاكل الأداء. حاول Mach 3 معالجة هذه المشكلة بتوفير نظام ترحيل بسيط، معتمدًا على أنظمة الترحيل في مساحة المستخدم لتحسين التخصيص. لكن تبين أن هذا الحل لم يكن فعالًا. عمليًا، تلاشت أي فوائد محتملة بسبب تكلفة الاتصال بين العمليات اللازمة لاستدعائه.

تضمنت مشاكل الأداء الأخرى دعم Mach لأنظمة المعالجات المتعددة . فمن منتصف الثمانينيات إلى أوائل التسعينيات، شهدت وحدات المعالجة المركزية التجارية نموًا في الأداء بمعدل 60% سنويًا، بينما لم تتجاوز سرعة الوصول إلى الذاكرة 7% سنويًا. هذا يعني أن تكلفة الوصول إلى الذاكرة ارتفعت بشكل كبير خلال هذه الفترة، ولأن Mach كان يعتمد على ربط الذاكرة بين البرامج، فإن أي "فقدان للذاكرة المؤقتة" كان يُبطئ استدعاءات IPC.

يُعدّ عبء الاتصال بين العمليات مشكلة رئيسية لأنظمة Mach 3. لا يزال مفهوم نظام التشغيل متعدد الخوادم واعدًا، مع أنه لا يزال بحاجة إلى مزيد من البحث. يجب على المطورين توخي الحذر لعزل التعليمات البرمجية في وحدات لا تتصل بين الخوادم. على سبيل المثال، يُوضع الجزء الأكبر من تعليمات الشبكة في خادم واحد، مما يقلل من عبء الاتصال بين العمليات في مهام الشبكة الاعتيادية.

بدلاً من ذلك، التزم معظم المطورين بمفهوم POE الأصلي، الذي يعتمد على خادم واحد كبير يوفر وظائف نظام التشغيل. ^{[ 17 ]} ولتسهيل عملية التطوير، سمحوا بتشغيل خادم نظام التشغيل إما في مساحة المستخدم أو في مساحة النواة. مكّنهم هذا من التطوير في مساحة المستخدم والاستفادة من جميع مزايا فكرة Mach الأصلية، ثم نقل الخادم الذي تم تصحيحه إلى مساحة النواة لتحسين الأداء. ومنذ ذلك الحين، تم بناء العديد من أنظمة التشغيل باستخدام هذه الطريقة، المعروفة باسم التجميع ، ومنها Lites و MkLinux و OSF/1 وNeXTSTEP/OPENSTEP/macOS. وقد جعلت نواة Chorus المصغّرة هذه الميزة جزءًا من النظام الأساسي، مما يسمح بتشغيل الخوادم في مساحة النواة باستخدام آليات مدمجة.

حاول نظام التشغيل Mach 4 معالجة هذه المشاكل من خلال مجموعة من التحسينات الجذرية. على وجه الخصوص، تبيّن أن شفرة البرنامج عادةً ما تكون غير قابلة للكتابة، لذا كانت احتمالية حدوث أخطاء بسبب النسخ عند الكتابة نادرة. وبالتالي، كان من المنطقي عدم ربط الذاكرة بين البرامج للتواصل بين العمليات، بل نقل شفرة البرنامج المستخدمة إلى المساحة المحلية للبرنامج. أدى هذا إلى ظهور مفهوم "المكوك"، وبدا أن الأداء قد تحسّن، لكن المطورين واصلوا العمل على النظام وهو في حالة شبه قابلة للاستخدام. كما قدّم نظام Mach 4 أيضًا أدوات التجميع المدمجة، مما جعلها جزءًا من نواة النظام.

بحلول منتصف التسعينيات، كان العمل على أنظمة النواة المصغرة راكدًا إلى حد كبير، على الرغم من أن السوق كان يعتقد عمومًا أن جميع أنظمة التشغيل الحديثة ستكون قائمة على النواة المصغرة بحلول التسعينيات. يُعد نظام macOS من Apple ونظام iOS الشقيق له من أبرز الاستخدامات المتبقية واسعة الانتشار لنواة Mach، حيث يعملان على نواة Mach هجينة معدلة بشكل كبير من مؤسسة البرمجيات المفتوحة (OSFMK 7.3) تُسمى " XNU " ^{[ 18 ]،} والتي تُستخدم أيضًا في OSF/1. ^{[ 10 ]} في XNU، تُنفذ أنظمة الملفات، ومكدسات الشبكات، ووظائف إدارة العمليات والذاكرة في النواة؛ ويتم استدعاء نظام الملفات والشبكات وبعض وظائف إدارة العمليات والذاكرة من وضع المستخدم عبر استدعاءات النظام العادية بدلًا من تمرير الرسائل؛ ^{[ 19 ] [ 20 ]} تُستخدم رسائل Mach في XNU للتواصل بين عمليات وضع المستخدم، ولبعض الطلبات من كود وضع المستخدم إلى النواة ومن النواة إلى خوادم وضع المستخدم.

أظهر تحليل إضافي أن مشكلة أداء الاتصال بين العمليات لم تكن واضحة كما بدت. تجدر الإشارة إلى أن تنفيذ جانب واحد من استدعاء النظام استغرق 20 ميكروثانية في نظام BSD ^{[ 3 ]} و114 ميكروثانية في نظام Mach الذي يعمل على نفس النظام. ^{[ 2 ]} من بين الـ 114 ميكروثانية، كان 11 ميكروثانية منها ناتجًا عن تبديل السياق، وهو ما يتطابق مع نظام BSD. ^{[ 14 ]} واستخدمت وحدة إدارة الذاكرة (MMU) 18 ميكروثانية إضافية لربط الرسالة بين مساحة المستخدم ومساحة النواة. ^{[ 3 ]} وبذلك يصل المجموع إلى 29 ميكروثانية فقط، وهي مدة أطول من استدعاء النظام التقليدي، ولكن ليس بفارق كبير.

أما الجزء الأكبر من المشكلة، فيعود إلى قيام نواة النظام بمهام مثل التحقق من صلاحيات الوصول إلى المنافذ في الرسالة. ^{[ 6 ]} ورغم أن هذا قد يبدو مصدر قلق أمني بالغ، إلا أنه في الواقع لا يُجدي نفعًا إلا في أنظمة شبيهة بنظام يونكس. فعلى سبيل المثال، قد لا يحتاج نظام تشغيل أحادي المستخدم، يُستخدم لتشغيل هاتف محمول أو روبوت، إلى أي من هذه الميزات، وهذا تحديدًا هو نوع النظام الذي يكون فيه نظام التشغيل "الاختياري" الخاص بـ Mach ذا قيمة كبيرة. وبالمثل، تسبب Mach في مشاكل عند نقل الذاكرة بواسطة نظام التشغيل، وهي مهمة أخرى لا تُجدي نفعًا إلا إذا كان النظام يحتوي على أكثر من مساحة عناوين. أما نظاما DOS و Mac OS في بداياتهما، فيحتويان على مساحة عناوين كبيرة واحدة مشتركة بين جميع البرامج، لذا لم يُوفر هذا التعيين أي فوائد في ظل هذه الأنظمة.

أدت هذه الاستنتاجات إلى ظهور سلسلة من النوى المصغرة من الجيل الثاني، والتي قللت من تعقيد النظام بشكل أكبر، ووضعت جميع الوظائف تقريبًا في مساحة المستخدم. على سبيل المثال، تتضمن نواة L4 (الإصدار 2) سبعة استدعاءات نظام فقط، وتستخدم 12 كيلوبايت من الذاكرة، ^{[ 3 ]} بينما تتضمن Mach 3 حوالي 140 دالة، وتستخدم حوالي 330 كيلوبايت من الذاكرة. ^{[ 3 ]} تستغرق استدعاءات الاتصال بين العمليات (IPC) في نواة L4 على معالج 486DX-50 خمس ميكروثانية فقط، ^{[ 20 ]} أي أسرع من استدعاء نظام UNIX على نفس النظام، وأسرع بأكثر من 20 مرة من Mach. بالطبع، هذا يتجاهل حقيقة أن L4 لا تتعامل مع الأذونات أو الأمان؛ ولكن بترك هذه المهمة لبرامج مساحة المستخدم، يمكنها اختيار مقدار الحمل الزائد الذي تحتاجه.

تُحدّ من المكاسب المحتملة في أداء طبقة التخزين L4 حقيقة أن تطبيقات مساحة المستخدم ستضطر غالبًا إلى توفير العديد من الوظائف التي كانت تدعمها النواة سابقًا. ولاختبار الأداء الشامل، قورن نظام MkLinux في وضع التشغيل المشترك مع منفذ L4 يعمل في مساحة المستخدم. أضافت طبقة التخزين L4 ما يقارب 5% إلى 10% من الحمل الزائد، ^{[ 14 ]} مقارنةً بنسبة 29% التي أضافها نظام Mach. ^{[ 14 ]}