جدولة جودة الخدمة في المركبات المزوّدة ببرامج

يوفّر إطار عمل جدولة جودة الخدمة (QoS) في المركبات المحدّدة بالبرامج تخصيصًا حتميًا لموارد وحدة المعالجة المركزية (CPU) لحِزم الخدمات التي يديرها تطبيق Lifecycle Manager (LM). ومن خلال تجريد سمات جدولة Linux المنخفضة المستوى (السياسة والأولوية واللطف) إلى إعدادات مسبقة منطقية، تتيح المنصة فصلًا واضحًا بين تطوير الخدمات وضبط النظام على مستوى المركبة. ويساعد ذلك في توفير معدل نقل بيانات ضروري للحوسبة لأحمال العمل الحساسة للوقت والمهمة للسلامة، بينما يقيّد النظام المهام التي تعمل في الخلفية لمنع عدم الاستقرار.

الأدوار والمسؤوليات

يتّبع نموذج جدولة SDV نمط المسؤولية المفوضة للمساعدة في ضمان بقاء الخدمات قابلة للنقل مع السماح لمصنّع المعدات الأصلية بضبط النظام.

سير العمل الفني

1. دمج النظام الأساسي: يحدّد المصنّع الأصلي للجهاز lifecycle_config.textproto الخاص بالمركبة. ينشئ هذا الملف ملفات شخصية (إعدادات مُسبقة) للجدولة على مستوى النظام ويربطها بسمات جدولة Linux المحدّدة استنادًا إلى الأجهزة المستهدَفة.
2. تطوير حِزمة الخدمات: يجمّع المطوّر scheduling_config.textproto ضِمن حِزمة APEX، ويقترح إعدادًا مسبقًا منطقيًا (مثل ELEVATED) ويحدّد أي أسماء سلاسل محادثات داخلية.
3. دمج حِزم الخدمات: أثناء مرحلة دمج المركبة، يراجع المصنّع الأصلي للجهاز الإعداد المُسبَق الذي اقترحه المطوّر. ويمكن للمصنّع الأصلي للجهاز الاحتفاظ بالملف الشخصي المقترَح أو إلغاء الإعدادات التلقائية، مثل خفض مستوى خدمة ELEVATED إلى NORMAL، لتحسين ثبات النظام بشكل عام قبل توقيع حزمة APEX.
4. حلّ سمات وقت التشغيل: عند بدء تشغيل إحدى الخدمات، يحدّد "مدير الأجهزة" الإعداد المُسبَق المصرّح به من بيان الخدمة ويسترد سمات Linux المقابلة من إعدادات النظام الخاصة بمصنّع المعدات الأصلية.
5. المزامنة والتنفيذ عند بدء التشغيل: يطبّق "مدير الترخيص" السمات التي تم تحديدها على عملية الخدمة قبل الإشارة إليها لمواصلة التنفيذ باستخدام بروتوكول الإشارة والمتابعة.

المفاهيم الأساسية

المفاهيم التالية أساسية لإطار عمل تحديد المواعيد في SDV.

إعدادات الجدولة المُسبقة

تُعدّ الإعدادات المُسبقة للجدولة الآلية هي الآلية الأساسية لإدارة جودة الخدمة في SDV. وبدلاً من تحديد مَعلمات الجدولة الأولية في Linux، يشير المطوّرون إلى الإعدادات المُسبقة المحدّدة مسبقًا بالاسم. وفي وقت التشغيل، تربط "إدارة الأجهزة" هذه الأسماء المنطقية بسمات الجدولة المحدّدة في Linux.

الإعدادات المُسبَقة التالية التي تم ضبطها كمثال في lifecycle_config.textproto:

عند تطبيق إعداد مُسبَق، تستخدم "إدارة الترخيص" طلب النظام setpriority لضبط قيمة nice على مستوى العملية. يؤثر ذلك في حصة وحدة المعالجة المركزية (CPU) النسبية التي تتلقّاها العملية أثناء التنازع بموجب برنامج Completely Fair Scheduler (CFS) التلقائي في نظام التشغيل Linux.

الامتيازات والأمان

لمنع تصعيد الأولوية غير المصرّح به، تستخدم منصة SDV نموذج أمان متدرّجًا يستند إلى نطاقات SELinux وإمكانات Linux.

نطاقات الأمان

• untrusted_service_bundle: النطاق التلقائي للإعدادات المسبقة العادية (NORMAL وELEVATED وIDLE). يقيّد النواة العمليات في هذا النطاق، ما يمنعها من تغيير مَعلمات الجدولة الخاصة بها.
• ‫priority_service_bundle: يتم منحها لأي حزمة خدمات تستخدم إعدادًا مُسبقًا تم فيه ضبط is_privileged: true في lifecycle_config.textproto على مستوى النظام. ويؤدي الانتقال إلى هذا النطاق إلى منح العملية إمكانية CAP_SYS_NICE، ما يتيح لها إدارة عملية تخصيص الموارد الخاصة بها.

إمكانية CAP_SYS_NICE

تمنح المنصة إذن الوصول إلى إمكانية CAP_SYS_NICE للعمليات في النطاق priority_service_bundle. يسمح هذا الإذن لأي عملية بتنفيذ ما يلي:

• رفع قيمة nice الخاصة به إلى ما هو أبعد من التعيين الأوّلي
• غيِّر سياسة الجدولة إلى صفوف في الوقت الفعلي، مثل SCHED_FIFO أو SCHED_RR.
• اضبط تقارب وحدة المعالجة المركزية باستخدام sched_setaffinity.
• ضبط مَعلمات الموعد النهائي المتخصّصة في SCHED_DEADLINE

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

دليل الإعداد

يقدّم هذا القسم إرشادات حول الإعداد لكلّ من الشركات المصنّعة للمعدات الأصلية ومطوّري الخدمات.

دليل المصنّع الأصلي للجهاز: الإعدادات المُسبَقة على مستوى النظام

يحدد المصنّع الأصلي للجهاز ملفات تعريف الجدولة في /product/etc/lifecycle_config.textproto. يقدّم النظام الأساسي مثالاً في lifecycle_management/config/lifecycle_config.textproto يُتوقّع من المصنّعين الأصليين للجهاز تعديله استنادًا إلى أجهزة السيارة.

مثال: تحديد إعداد مُسبَق في الوقت الفعلي

يمكن أن تحدّد الشركة المصنّعة للجهاز إعدادًا مُسبقًا CRITICAL للخدمات المتعلّقة بالسلامة والتي يجب ألا يتم إيقافها مؤقتًا من قِبل التطبيقات العادية:

# lifecycle_config.textproto
scheduling_presets {
  name: "CRITICAL"
  is_privileged: true
  thread_scheduling_configuration {
    policy: 1      # SCHED_FIFO
    priority: 80   # High real-time priority
  }
}

دليل المطوّرين: إعداد حِزم الخدمات

ينصح مطوّرو الخدمات باستخدام إعداد مُسبَق وتحديد أسماء سلاسل محادثات منطقية اختياريًا في ملف scheduling_config.textproto. لكي يتمكّن النظام الأساسي من العثور على هذا الملف، يجب تسجيل مساره في sdv_service_bundles_manifest.textproto.

مثال: تسجيل ملف البيان

# sdv_service_bundles_manifest.textproto
service_bundle_entries {
  name: "SensorService"
  scheduling_config_path: "configs/scheduling_config.textproto"
}

مثال: استخدام إعداد مسبق عادي

بالنسبة إلى معظم الخدمات، يكفي الإشارة إلى اسم مُعدّ مسبقًا في scheduling_config.textproto:

# configs/scheduling_config.textproto
scheduling_preset_name: "ELEVATED"

مثال: تحديد موعد لتنفيذ سلاسل عاملة تم إنشاؤها بواسطة الخدمة

يمكن لمطوّر خدمة إنشاء سلاسل الوحدات العاملة (worker thread) إضافية في الرمز البرمجي للتعامل مع مهام متخصصة، مثل حلقة بيانات جهاز الاستشعار بزمن انتقال منخفض. يمكن للمطوّر تحديد سمات جدولة مسماة لهذه سلاسل المحادثات الداخلية في ملف الإعداد.

استخدِم التطبيق اليدوي فقط في الخدمات المميّزة التي تستخدم هذه البيانات الوصفية لضبط خصائص سلاسل العامل الداخلية:

# configs/scheduling_config.textproto
scheduling_preset_name: "CUSTOM"

# Map of logical thread names to their attributes (propagated as metadata)
thread_scheduling_configuration {
  key: "sensor-processing-thread"
  value {
    policy: 1        # SCHED_FIFO
    priority: 50
    cpu_affinity_ids: [2, 3]  # Pin to specific cores
  }
}

سلوك النظام وإجراءات التنفيذ

تستخدم منصة SDV نموذجًا صارمًا للتنفيذ لتفعيل إعدادات الجدولة قبل تشغيل أي رمز خاص بالخدمة.

مزامنة بدء التشغيل

لمنع تشغيل خدمة بأولوية غير صحيحة (حتى أثناء مرحلة الإعداد)، يستخدم كلّ من LM وService Bundle Runner (SBR) بروتوكول مزامنة الإشارة والمتابعة:

1. إنشاء العملية: ينشئ LM نسخة من عملية SBR. في هذه المرحلة، تكون عملية SBR الفرعية قيد التشغيل ولكنها تدخل على الفور في حالة محظورة، في انتظار إشارة على stdin.
2. تطبيق السمة: عندما يكون الطفل محظورًا، تستخدم "إدارة الوصول" طلب النظام setpriority لتطبيق القيمة nice المطلوبة وتضبط سياسة الجدولة (مثل SCHED_IDLE).
3. عملية الانتقال إلى وضع الأمان: ينفّذ LM عملية الانتقال إلى نطاق SELinux، وينقل العملية الفرعية إلى النطاق untrusted_service_bundle أو priority_service_bundle.
4. الإشارة: بعد تطبيق جميع المَعلمات بنجاح، يرسل "مدير الترخيص" إشارة مكوّنة من بايت واحد إلى stdin الخاص بالطفل.
5. التنفيذ: يتلقّى SBR الإشارة ويبدأ في تحميل مكتبات الخدمة واستدعاء طرق مراحل النشاط.

التأثير في سلسلة التعليمات الرئيسية ودورة الحياة

من خلال المزامنة قبل تحميل مكتبات الخدمة، تحافظ المنصة على الأولوية المطلوبة لسلسلة التنفيذ الرئيسية في جميع عمليات معاودة الاتصال بدورة الحياة:

• onCreate: يتم تنفيذ جميع عمليات إدخال التبعية وتخصيص الموارد الأولي بالأولوية الصحيحة.
• ‫onStart: يتحكّم الإعداد المُسبَق في الانتقال إلى الحالة النشطة وأي حلقات عمل أولية.
• onStop وonDestroy: تنفّذ المنصة عمليات تنظيف بالأولوية نفسها لمنع حرمان أنشطة النظام المهمة من الموارد أثناء إيقاف التشغيل.

مجموعة سلاسل Binder وأولوية التوريث

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

الضبط الدقيق على مستوى سلسلة المحادثات

يجب أن تطبّق حِزم الخدمات التي تتطلّب تحكّمًا دقيقًا (مثل حلقات المعالجة في الوقت الفعلي) عمليات الضبط يدويًا على سلاسل العاملين. اتّبِع الخطوات التالية لتطبيق عمليات الضبط على مستوى السلسلة:

1. طلب إعداد مُسبَق بامتيازات (حيث يتم ضبط is_privileged: true).
2. استخدِم الدالة get_scheduling_configuration من مكتبة sdv_service_bundles_scheduling لقراءة thread_scheduling_configuration.
3. طبِّق السمات على سلاسل العامل باستخدام sched_setattr.

‫SELinux وإنفاذ القدرات

تستخدم المنصة SELinux وCAP_SYS_NICE Linux لفرض إعدادات مسبقة للجدولة:

• بالنسبة إلى الخدمات التي تستخدم إعدادات مُسبقة مثل NORMAL أو IDLE، يتم ضبط الجدولة من قِبل "مدير الربط" أثناء بدء التشغيل. ولا تتضمّن هذه الخدمات إمكانية CAP_SYS_NICE ولا يمكنها تغيير أولويتها أو سياستها.
• يتم منح الخدمات التي تستخدم إعدادًا مسبقًا ذا امتيازات (is_privileged: true) إمكانية CAP_SYS_NICE، ما يتيح لها التحكّم يدويًا في جدولة سلاسل التعليمات البرمجية الداخلية، حسب ما هو مطلوب للمهام في الوقت الفعلي.

التحقّق من صحة المعلومات والأمثلة

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

مثال على جدولة جودة الخدمة

يقع هذا النموذج في samples/qos_scheduling، ويتضمّن العديد من خدمات اختبار الأداء المصمّمة للعمل بالتوازي والإبلاغ عن مستوى تقدّمها.

• ‫PerformanceTesterNormal: يتم تشغيلها باستخدام الإعداد المُسبَق NORMAL.
• ‫PerformanceTesterElevated: يتم تشغيلها باستخدام الإعداد المُسبَق ELEVATED.
• ‫PerformanceTesterRealtime: تستخدم الإعداد المُسبَق CUSTOM لتطبيق SCHED_FIFO على سلاسل العامل الداخلية.
• PolicyOffender: هي خدمة تشخيص تحاول ضبط أولوية في الوقت الفعلي أثناء استخدام إعداد مسبق NORMAL. يتم استخدام ذلك للتأكّد من أنّ النظام الأساسي يحظر التصعيد غير المصرَّح به بنجاح.

تشغيل حزمة أدوات التحقّق

1. فعِّل إعداد التنسيق الخاص بجودة الخدمة:

   adb shell setprop persist.sdv.orchestrator_config_path /etc/orch/vm_qos_scheduling_orch_config.textproto

2. أعِد تشغيل الجهاز لبدء الخدمات في نطاقات الجدولة الخاصة بها:

   adb reboot

3. فلتر السجلات للاطّلاع على نتائج الأداء المقارن:

   adb logcat | grep sdv_sample_qos_common

   تسجّل خدمة PerformanceTesterElevated عددًا أكبر بكثير من وحدات العمل المكتملة مقارنةً بخدمة PerformanceTesterNormal. يتم تضمين أخطاء الرفض EPERM أو SELinux في سجلّات خدمة PolicyOffender.

التوافق مع الأنظمة القديمة

• لضمان التوافق مع الإصدارات القديمة، يتم تلقائيًا التعامل مع أي حِزمة خدمة قديمة تحدّد scheduling_config_path في ملف البيان ولكنها لا تحدّد scheduling_preset_name في ملف الإعداد على أنّها خدمة ذات امتيازات، ما يحافظ على الإمكانات اللازمة (مثل CAP_SYS_NICE) للخدمات القديمة التي تعتمد على الضبط اليدوي لسلسلة التعليمات البرمجية.
• من المقرّر إعادة تسمية رسالة الإعدادات الجذرية DeadlineSchedulingConfiguration في إصدار مستقبلي. الاسم الحالي قديم ولم يعُد يعكس بدقة أنّ الرسالة تعالج جميع أنواع الجدولة، وليس فقط جدولة المواعيد النهائية.