نواة ويندوز الأحادية

يعد Windows أحد أكثر أنظمة التشغيل مرونة ومتعددة الأوجه ، وهو يعمل على بنى مختلفة تمامًا ومتوفر في إصدارات مختلفة. وهي اليوم تدعم البنى x86 و x64 و ARM و ARM64. دعم Windows في وقت واحد Itanium و PowerPC و DEC Alpha و MIPS. بالإضافة إلى ذلك ، يدعم Windows مجموعة كبيرة من وحدات SKU التي تعمل في ظروف مختلفة ؛ من مراكز البيانات وأجهزة الكمبيوتر المحمولة وأجهزة Xbox والهواتف إلى الإصدارات المضمنة من إنترنت الأشياء ، على سبيل المثال ، في أجهزة الصراف الآلي.

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

في هذه المقالة ، سأتحدث عن تطور الأجزاء الرئيسية من نواة Windows التي تمكنها من التوسع بشفافية من رقاقة NVidia Tegra منخفضة الطاقة التي تعمل على Surface RT 2012 إلى الوحوش العملاقة التي تعمل في مراكز بيانات Azure.


مدير مهام Windows يعمل على جهاز Windows DataCenter التجريبي ، مع 896 نواة تدعم 1792 معالج منطقي و 2 تيرابايت من الذاكرة

تطور جوهر واحد

قبل مناقشة تفاصيل Windows kernel ، دعنا نتطرق قليلاً نحو إعادة الهيكلة . تلعب إعادة الهيكلة دورًا رئيسيًا في زيادة إعادة استخدام مكونات نظام التشغيل على وحدات SKU والمنصات المختلفة (على سبيل المثال ، العميل والخادم والهاتف). تتمثل الفكرة الأساسية لإعادة الهيكلة في السماح لك بإعادة استخدام نفس مكتبة الارتباط الديناميكي على وحدات SKU مختلفة ، ودعم التعديلات الصغيرة التي تم إجراؤها خصيصًا لرمز التخزين التعريفي المطلوب ، دون إعادة تسمية مكتبة الارتباط الحيوي (DLL) ودون كسر عمل التطبيقات.

التكنولوجيا الأساسية لإعادة بناء Windows هي تقنية صغيرة التوثيق تسمى مجموعات API . مجموعات API هي آلية تسمح لنظام التشغيل بفصل DLL ومكان استخدامه. على سبيل المثال ، تسمح مجموعة واجهة برمجة التطبيقات للتطبيقات الخاصة بـ win32 بالاستمرار في استخدام kernel32.dll ، على الرغم من حقيقة أن تنفيذ جميع واجهات برمجة التطبيقات مكتوب في ملف DLL آخر. قد تختلف مكتبات DLL للتنفيذ أيضًا بين وحدات SKU. يمكنك مشاهدة مجموعات واجهة برمجة التطبيقات بشكل عملي عن طريق تشغيل اجتياز التبعية على DLL Windows تقليدي ، على سبيل المثال ، kernel32.dll.


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

مكونات النواة

Windows NT ، في الواقع ، هو microkernel ، بمعنى أنه يحتوي على نواة Kernel (KE) الخاصة به مع مجموعة محدودة من الوظائف ، وذلك باستخدام الطبقة القابلة للتنفيذ (الطبقة التنفيذية ، Ex) لتنفيذ جميع السياسات عالية المستوى. EX لا يزال في وضع kernel ، لذا فهو ليس نواة دقيقة تمامًا. النواة مسؤولة عن جدولة سلاسل العمليات ، والمزامنة بين المعالجات ، ومعالجة الاستثناءات على مستوى الأجهزة ، وتنفيذ الوظائف المنخفضة المستوى المعتمدة على الأجهزة. تحتوي طبقة EX على العديد من الأنظمة الفرعية التي توفر مجموعة من الوظائف التي تعتبر عادةً جوهر - IO ، Object Manager ، Memory Manager ، Process Subsystem ، إلخ.


لفهم حجم المكونات بشكل أفضل ، فيما يلي تحليل تقريبي لعدد سطور التعليمات البرمجية في العديد من الأدلة الرئيسية لشجرة مصدر kernel (بما في ذلك التعليقات). لم يتضمن الجدول بعد الكثير من كل ما يتعلق بالنواة.

النظم الفرعية Kernel	خطوط الكود
مدير الذاكرة	501000
التسجيل	211،000
القوة	238000
تنفيذي	157000
الأمن	135000
نواة	339000
معالجة النظام الفرعي	116،000

لمزيد من المعلومات حول هندسة Windows ، راجع سلسلة كتاب Windows Internals .

مخطط

بعد تحضير الأرضية بهذه الطريقة ، دعنا نتحدث قليلاً عن المجدول وتطوره وكيف يمكن لنواة Windows أن تتطور إلى عدد من البنى المختلفة مع العديد من المعالجات.

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

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

كان لدى Windows Scheduler في البداية قائمة انتظار جاهزة واحدة ، حدد منها مؤشر الترابط التالي الأعلى أولوية ليتم تشغيله. ومع ذلك ، مع بداية الدعم لعدد متزايد من المعالجات ، تحولت قائمة الانتظار الوحيدة إلى عنق الزجاجة ، وقام الجدولة بتغيير العمل حول منطقة إصدار Windows Server 2003 وتنظيم قائمة انتظار جاهزة لكل معالج. عند التبديل إلى دعم طلبات متعددة لمعالج واحد ، لم يفعلوا قفلًا عامًا واحدًا لحماية جميع قوائم الانتظار ، وسمحوا للجدولة باتخاذ قرارات بناءً على أوبتيما المحلية. وهذا يعني أنه يوجد في أي لحظة في النظام مؤشر ترابط واحد له الأولوية القصوى ، ولكنه لا يعني بالضرورة أن N من مؤشرات الترابط ذات الأولوية الأعلى في القائمة (حيث N هو عدد المعالجات) تعمل في النظام. هذا النهج يؤتي ثماره حتى يبدأ Windows في التبديل إلى وحدات المعالجة المركزية منخفضة الطاقة مثل أجهزة الكمبيوتر المحمولة والأجهزة اللوحية. عندما لم يعمل الخيط ذي الأولوية القصوى على مثل هذه الأنظمة (على سبيل المثال ، الخيط الأمامي لواجهة المستخدم) ، أدى ذلك إلى حدوث خلل ملحوظ في الواجهة. لذلك ، في Windows 8.1 ، تم نقل المجدول إلى نموذج هجين ، مع قوائم انتظار لكل معالج للخيوط المرتبطة بهذا المعالج ، وقائمة انتظار مشتركة للعمليات الجاهزة لجميع المعالجات. لم يؤثر هذا على الأداء بشكل ملحوظ بسبب التغييرات الأخرى في هندسة الجدولة ، على سبيل المثال ، إعادة هيكلة قفل قاعدة بيانات المرسل.

قدم Windows 7 شيء مثل جدولة مشاركة عادلة ديناميكية (Dynamic Fair Share Scheduler ، DFSS) ؛ يتعلق هذا بشكل أساسي بالخوادم الطرفية. حاولت هذه الميزة حل المشكلة المتمثلة في أن جلسة عمل طرفية واحدة ذات حمل مرتفع لوحدة المعالجة المركزية قد تؤثر على سلاسل الرسائل في جلسات عمل طرفية أخرى. نظرًا لأن المجدول لم يأخذ في الاعتبار الجلسات واستخدم ببساطة الأولوية لتوزيع التدفقات ، يمكن للمستخدمين في جلسات مختلفة التأثير على عمل المستخدمين في جلسات أخرى عن طريق خنق تدفقاتهم. كما أعطت ميزة غير عادلة للجلسات (والمستخدمين) التي تحتوي على عدد كبير من سلاسل المحادثات ، حيث أن الجلسة التي تحتوي على عدد كبير من سلاسل المحادثات لديها فرص أكثر للحصول على وقت المعالج. جرت محاولة لإضافة قاعدة إلى المجدول ، حيث تم اعتبار كل جلسة على قدم المساواة مع الآخرين من حيث وقت المعالج. توجد وظائف مماثلة في Linux مع برنامج جدولة نزيه تمامًا ( جدولة عادلة تمامًا ). في Windows 8 ، تم تعميم هذا المفهوم كمجموعة جدولة وإضافته إلى المجدول ، ونتيجة لذلك سقطت كل جلسة في مجموعة مستقلة. بالإضافة إلى أولويات سلاسل الرسائل ، يستخدم المجدول مجموعات المجدول كفهرس من المستوى الثاني ، ويحدد مؤشر الترابط الذي سيبدأ بعد ذلك. في الخادم الطرفي ، يكون لجميع مجموعات المجدول نفس الوزن ، لذلك تتلقى جميع الجلسات نفس مقدار وقت المعالج ، بغض النظر عن عدد أو أولوية سلاسل العمليات ضمن مجموعات المجدول. بالإضافة إلى ذلك ، يتم استخدام هذه المجموعات أيضًا للتحكم بشكل أكثر دقة في العمليات. في Windows 8 ، تم تحسين كائنات المهمة لدعم إدارة وقت المعالج . باستخدام واجهة برمجة تطبيقات خاصة ، يمكنك تحديد مقدار وقت المعالج الذي يمكن أن تستخدمه العملية ، إذا كان الحد الأدنى أو الثابت ، وتلقي الإخطارات عندما تصل العملية إلى هذه الحدود. هذا مشابه لإدارة الموارد في مجموعات cg على Linux.

بدءًا من Windows 7 ، قدم Windows Server دعمًا لأكثر من 64 معالج منطقي على جهاز كمبيوتر واحد. لإضافة دعم للعديد من المعالجات ، تم إدخال فئة جديدة في النظام ، "مجموعة المعالجات". المجموعة هي مجموعة ثابتة من المعالجات المنطقية التي لا تزيد عن 64 قطعة ، والتي يعتبرها المجدول وحدة حاسوبية. تحدد النواة عند التمهيد أي معالج ينتمي إلى أي مجموعة ، وبالنسبة للأجهزة التي تحتوي على أقل من 64 نواة معالج ، يكاد يكون من المستحيل ملاحظة هذا النهج. يمكن تقسيم عملية واحدة إلى عدة مجموعات (على سبيل المثال ، مثيل خادم SQL) ، ولا يمكن تنفيذ مؤشر ترابط واحد في نفس الوقت إلا داخل نفس المجموعة.

ولكن على الأجهزة التي يتجاوز فيها عدد نوى وحدة المعالجة المركزية 64 ، بدأ Windows في إظهار اختناقات جديدة منعت التطبيقات الصعبة مثل خادم SQL من التوسع بشكل خطي مع العدد المتزايد من نوى المعالج. لذلك ، حتى مع إضافة النوى والذاكرة الجديدة ، لم تظهر قياسات السرعة زيادة كبيرة. واحدة من المشاكل الرئيسية المرتبطة بذلك كانت الخلاف حول حجب قاعدة المرسل. قفل قاعدة بيانات المرسل يحمي الوصول إلى الأشياء التي كان يجب تخطيط عملها. من بين هذه الأشياء هي الخيوط ، المؤقتات ، منافذ الإدخال / الإخراج ، كائنات kernel الأخرى التي تخضع للانتظار (الأحداث ، الإشارات ، كائنات المزامنة). تحت ضغط من الحاجة إلى حل مثل هذه المشاكل ، في Windows 7 ، تم العمل على إزالة حظر قاعدة بيانات المرسل واستبدالها بتعديلات أكثر دقة ، على سبيل المثال ، قفل كائن تلو الآخر. سمح هذا لقياسات الأداء مثل SQL TPC-C بإظهار زيادة في السرعة بنسبة 290٪ مقارنة بالمخطط السابق في بعض التكوينات. كانت واحدة من أكبر عمليات زيادة الأداء في تاريخ Windows التي حدثت بسبب تغيير في ميزة واحدة.

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

أخيرًا ، نأتي إلى دعم ARM64 ، الذي ظهر في Windows 10 . تدعم بنية ARM البنية الكبيرة. LITTLE ، وهي غير متجانسة في طبيعتها - النواة "الكبيرة" سريعة وتستهلك الكثير من الطاقة ، والنواة "الصغيرة" بطيئة وتستهلك أقل. الفكرة هي أن المهام غير المهمة يمكن إجراؤها على قلب صغير ، وبالتالي توفير البطارية. لدعم بنية big.LITTLE وزيادة عمر البطارية عند تشغيل Windows 10 على ARM ، تمت إضافة دعم تخطيط غير متجانس إلى المجدول ، مع مراعاة رغبات تطبيق يعمل مع بنية big.LITTLE.

من خلال الرغبات ، أعني أن Windows يحاول توفير خدمة عالية الجودة للتطبيقات ، وتتبع سلاسل الرسائل التي يتم تشغيلها في المقدمة (أو تلك التي تفتقر إلى وقت المعالج) ، وضمان تنفيذها على القلب "الكبير". تعمل جميع مهام الخلفية والخدمات وسلاسل العمليات المساعدة الأخرى على نوى صغيرة. أيضا في البرنامج ، يمكنك أن تلاحظ بالقوة الأهمية المنخفضة للخيط لجعله يعمل على النواة الصغيرة.

العمل نيابة عن شخص آخر [Work on Behalf]: في Windows ، يتم تنفيذ الكثير من العمل في المقدمة بواسطة خدمات أخرى تعمل في الخلفية. على سبيل المثال ، عند البحث في Outlook ، يتم إجراء البحث نفسه بواسطة خدمة خلفية المفهرس. إذا قمنا فقط بتشغيل جميع الخدمات على نواة صغيرة ، فسوف تعاني جودة وسرعة التطبيقات في المقدمة. لمنعه من التباطؤ في بنى LITTLE الكبيرة في ظل سيناريوهات العمل هذه ، يراقب Windows مكالمات التطبيق الواردة إلى العمليات الأخرى من أجل أداء العمل نيابة عنها. في هذه الحالة ، نعطي أولوية المقدمة لمؤشر الترابط المتعلق بالخدمة ونجبرها على العمل على قلب كبير.

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