زمان‌بندی کیفیت خدمات در SDV

چارچوب زمان‌بندی کیفیت خدمات (QoS) SDV، تخصیص قطعی منابع CPU را برای بسته‌های خدماتی که توسط مدیر چرخه عمر (LM) مدیریت می‌شوند، فراهم می‌کند. این پلتفرم با خلاصه کردن ویژگی‌های زمان‌بندی سطح پایین لینوکس (سیاست، اولویت، خوب) به پیش‌فرض‌های منطقی، امکان جداسازی دقیق بین توسعه خدمات و تنظیم سیستم در سطح خودرو را فراهم می‌کند. این امر به تأمین پهنای باند محاسباتی لازم برای بارهای کاری حساس به ایمنی و حساس به زمان کمک می‌کند، در حالی که سیستم وظایف پس‌زمینه را برای جلوگیری از بی‌ثباتی محدود می‌کند.

نقش‌ها و مسئولیت‌ها

مدل زمان‌بندی SDV از یک الگوی تفویض مسئولیت پیروی می‌کند تا اطمینان حاصل شود که سرویس‌ها قابل حمل باقی می‌مانند و در عین حال به OEM اجازه می‌دهد سیستم را تنظیم کند.

گردش کار فنی

1. یکپارچه‌سازی پلتفرم: تولیدکننده اصلی (OEM) فایل lifecycle_config.textproto مختص خودرو را تعریف می‌کند. این فایل، پروفایل‌های زمان‌بندی (از پیش تنظیم شده‌ها) در سطح سیستم را ایجاد کرده و آنها را بر اساس سخت‌افزار هدف، به ویژگی‌های زمان‌بندی لینوکس نگاشت می‌کند.
2. توسعه بسته سرویس: توسعه‌دهنده یک scheduling_config.textproto را در بسته APEX خود قرار می‌دهد، یک پیش‌تنظیم منطقی (مثلاً ELEVATED ) را پیشنهاد می‌دهد و نام‌های نخ داخلی را تعریف می‌کند.
3. ادغام بسته خدمات: در طول مرحله ادغام خودرو، OEM تنظیمات از پیش تعیین‌شده پیشنهادی توسعه‌دهنده را بررسی می‌کند. OEM می‌تواند پروفایل پیشنهادی را حفظ کند یا آن را لغو کند، مانند کاهش سطح یک سرویس ELEVATED به NORMAL ، تا پایداری کلی سیستم را قبل از امضای APEX بهبود بخشد.
4. تفکیک ویژگی زمان اجرا: هنگامی که یک سرویس آغاز می‌شود، LM از پیش تعیین‌شده‌ی مجاز را از مانیفست سرویس شناسایی کرده و ویژگی‌های لینوکس مربوطه را از پیکربندی سیستم OEM بازیابی می‌کند.
5. همگام‌سازی و اجرای راه‌اندازی: LM ویژگی‌های تعیین‌شده را قبل از ارسال سیگنال برای ادامه اجرا با استفاده از پروتکل signal-and-continue، به فرآیند سرویس اعمال می‌کند.

مفاهیم اصلی

مفاهیم زیر در چارچوب زمان‌بندی SDV نقش اساسی دارند.

زمان‌بندی از پیش تعیین‌شده

تنظیمات از پیش تعیین‌شده‌ی زمان‌بندی، سازوکار اصلی مدیریت QoS در SDV هستند. توسعه‌دهندگان به جای تعریف پارامترهای خام زمان‌بندی لینوکس، به تنظیمات از پیش تعریف‌شده با نام ارجاع می‌دهند. در زمان اجرا، LM این نام‌های منطقی را به ویژگی‌های زمان‌بندی لینوکس نگاشت می‌کند.

تنظیمات پیش‌فرض زیر به عنوان مثال در lifecycle_config.textproto پیکربندی شده‌اند:

هنگام اعمال یک پیش‌تنظیم، LM از فراخوانی سیستمی setpriority برای تنظیم مقدار nice در کل فرآیند استفاده می‌کند. این امر بر سهم نسبی CPU که فرآیند در طول رقابت تحت زمانبند کاملاً منصفانه لینوکس (CFS) دریافت می‌کند، تأثیر می‌گذارد.

امتیاز و امنیت

برای جلوگیری از افزایش اولویت غیرمجاز، پلتفرم SDV از یک مدل امنیتی لایه‌ای مبتنی بر دامنه‌های SELinux و قابلیت‌های لینوکس استفاده می‌کند.

دامنه‌های امنیتی

• 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 وابستگی CPU را تنظیم کنید.
• پارامترهای مهلت ویژه برای SCHED_DEADLINE را پیکربندی کنید.

محدود کردن این قابلیت به یک دامنه اختصاصی، با محدود کردن اختلالات در سرویس‌های دارای مجوز صریح، از تعادل زمان‌بندی در کل سیستم محافظت می‌کند.

راهنمای پیکربندی

این بخش، راهنمایی‌های پیکربندی را برای تولیدکنندگان اصلی تجهیزات (OEM) و توسعه‌دهندگان خدمات ارائه می‌دهد.

راهنمای OEM: تنظیمات از پیش تعیین‌شده در کل سیستم

تولیدکننده اصلی (OEM) پروفایل‌های زمان‌بندی را در /product/etc/lifecycle_config.textproto تعریف می‌کند. این پلتفرم مثالی را در lifecycle_management/config/lifecycle_config.textproto ارائه می‌دهد که انتظار می‌رود تولیدکنندگان اصلی (OEM) آن را بر اساس سخت‌افزار خودرو تنظیم کنند.

مثال: تعریف یک پیش‌تنظیم بلادرنگ

یک تولیدکننده تجهیزات اصلی (OEM) ممکن است یک پیش‌تنظیم 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"

مثال: زمان‌بندی برای نخ‌های کارگر تولید شده توسط سرویس

یک توسعه‌دهنده سرویس ممکن است رشته‌های کاری اضافی را در کد خود ایجاد کند تا وظایف تخصصی مانند یک حلقه داده حسگر با تأخیر کم را مدیریت کند. توسعه‌دهنده می‌تواند ویژگی‌های زمان‌بندی نامگذاری‌شده را برای این رشته‌های داخلی در فایل پیکربندی تعریف کند.

فقط در سرویس‌های ممتازی که از این فراداده برای تنظیم ویژگی‌های نخ‌های کارگر داخلی خود استفاده می‌کنند، از اعمال دستی استفاده کنید:

# 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) از یک پروتکل همگام‌سازی signal-and-continue استفاده می‌کنند:

1. ایجاد فرآیند: LM فرآیند SBR را منشعب می‌کند. در این مرحله، فرآیند فرزند SBR در حال اجرا است اما بلافاصله وارد حالت مسدود شده می‌شود و منتظر سیگنالی از stdin خود می‌ماند.
2. کاربرد ویژگی: در حالی که فرزند مسدود شده است، LM از فراخوانی سیستمی setpriority برای اعمال مقدار nice درخواستی استفاده می‌کند و سیاست زمان‌بندی (برای مثال، SCHED_IDLE ) را پیکربندی می‌کند.
3. انتقال امنیتی: LM انتقال دامنه SELinux را انجام می‌دهد و فرزند را به دامنه untrusted_service_bundle یا priority_service_bundle منتقل می‌کند.
4. سیگنال: تنها پس از اعمال موفقیت‌آمیز همه پارامترها، LM یک سیگنال تک‌بایتی به stdin فرزند ارسال می‌کند.
5. اجرا: SBR سیگنال را دریافت می‌کند و شروع به بارگذاری کتابخانه‌های سرویس و فراخوانی متدهای چرخه حیات می‌کند.

تأثیر بر نخ اصلی و چرخه حیات

با همگام‌سازی قبل از بارگذاری کتابخانه‌های سرویس، پلتفرم اولویت درخواستی برای نخ اجرایی اصلی را در تمام فراخوانی‌های چرخه عمر حفظ می‌کند:

• onCreate : تمام تزریق وابستگی‌ها و تخصیص اولیه منابع با اولویت صحیح انجام می‌شوند.
• onStart : این پیش‌تنظیم، انتقال به حالت فعال و هرگونه حلقه کاری اولیه را کنترل می‌کند.
• onStop و onDestroy : این پلتفرم عملیات پاکسازی را با اولویت یکسان انجام می‌دهد تا از اتلاف فعالیت‌های حیاتی سیستم در هنگام خاموش شدن جلوگیری کند.

مخزن نخ‌های اتصال‌دهنده و وراثت اولویت‌دار

نخ‌های موجود در مخزن نخ‌های Binder که توسط پلتفرم مدیریت می‌شوند، کار را با اولویت نخی که مخزن را ایجاد کرده است، اجرا نمی‌کنند. در عوض، برای تراکنش‌های همزمان، نخ سرور اولویت فراخواننده را به ارث می‌برد. درایور هسته Binder این مکانیسم ارث‌بری اولویت را کنترل می‌کند.

تنظیم دقیق در سطح نخ

بسته‌های خدماتی که نیاز به کنترل جزئی دارند (برای مثال، حلقه‌های پردازش بلادرنگ) باید پیکربندی‌ها را به صورت دستی روی نخ‌های کارگر خود اعمال کنند. برای اعمال پیکربندی‌های سطح نخ، از مراحل زیر استفاده کنید:

1. درخواست یک پیش‌تنظیم ممتاز (که در آن is_privileged: true تنظیم شده است).
2. برای خواندن thread_scheduling_configuration از تابع get_scheduling_configuration از کتابخانه sdv_service_bundles_scheduling استفاده کنید.
3. با استفاده از sched_setattr ویژگی‌ها را به نخ‌های کارگر اعمال کنید.

SELinux و اجرای قابلیت‌ها

این پلتفرم از SELinux و قابلیت CAP_SYS_NICE لینوکس برای اعمال تنظیمات از پیش تعیین‌شده‌ی زمان‌بندی استفاده می‌کند:

• برای سرویس‌هایی که از تنظیمات پیش‌فرض مانند NORMAL یا IDLE استفاده می‌کنند، زمان‌بندی توسط LM در هنگام راه‌اندازی پیکربندی می‌شود. این سرویس‌ها قابلیت CAP_SYS_NICE را ندارند و نمی‌توانند اولویت یا سیاست خود را تغییر دهند.
• سرویس‌هایی که از یک پیش‌تنظیم ممتاز ( is_privileged: true ) استفاده می‌کنند، قابلیت CAP_SYS_NICE را دریافت می‌کنند. این قابلیت به آن‌ها اجازه می‌دهد تا زمان‌بندی نخ‌های داخلی خود را، همانطور که برای وظایف بلادرنگ مورد نیاز است، به صورت دستی کنترل کنند.

تأیید و نمونه‌ها

تأیید رفتار زمان‌بندی نیازمند ترکیبی از تحلیل لاگ و اندازه‌گیری عملکرد در سطح سیستم است. پلتفرم SDV یک نمونه اختصاصی برای نمایش این تکنیک‌ها ارائه می‌دهد.

نمونه زمان‌بندی QoS

این نمونه که در samples/qos_scheduling قرار دارد، شامل چندین سرویس تست عملکرد است که برای اجرا به صورت موازی و گزارش پیشرفت خود طراحی شده‌اند.

• PerformanceTesterNormal : با تنظیمات پیش‌فرض NORMAL اجرا می‌شود.
• PerformanceTesterElevated : با تنظیمات پیش‌فرض ELEVATED اجرا می‌شود.
• PerformanceTesterRealtime : از تنظیمات پیش‌فرض CUSTOM برای اعمال SCHED_FIFO به نخ‌های کارگر داخلی خود استفاده می‌کند.
• PolicyOffender : یک سرویس تشخیصی که تلاش می‌کند با استفاده از یک پیش‌فرض NORMAL اولویت بلادرنگ را تعیین کند. این سرویس برای تأیید اینکه پلتفرم با موفقیت افزایش غیرمجاز را مسدود می‌کند، استفاده می‌شود.

مجموعه تأیید را اجرا کنید

1. پیکربندی هماهنگ‌سازی مختص QoS را فعال کنید:

   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 is scheduled to change in a future release» در نسخه آینده تغییر نام خواهد داد. نام فعلی قدیمی است و دیگر به طور دقیق نشان نمی‌دهد که این پیام همه انواع زمان‌بندی، و نه فقط زمان‌بندی مهلت، را مدیریت می‌کند.