Penjadwalan kualitas layanan di SDV

Framework penjadwalan kualitas layanan (QoS) SDV menyediakan alokasi resource CPU deterministik untuk paket layanan yang dikelola oleh Lifecycle Manager (LM). Dengan mengabstraksi atribut penjadwalan Linux tingkat rendah (Kebijakan, Prioritas, Nice) ke dalam preset logis, platform ini memungkinkan pemisahan yang jelas antara pengembangan layanan dan penyesuaian sistem di seluruh kendaraan. Hal ini membantu menyediakan bandwidth komputasi yang diperlukan untuk beban kerja yang penting bagi keselamatan dan sensitif terhadap waktu, sementara sistem membatasi tugas latar belakang untuk mencegah ketidakstabilan.

Peran dan tanggung jawab

Model penjadwalan SDV mengikuti pola tanggung jawab yang didelegasikan untuk membantu memastikan layanan tetap portabel sekaligus memungkinkan OEM menyesuaikan sistem.

Peran Tanggung jawab Hasil utama
Platform SDV (Google) Menentukan skema sdv_service_bundles_scheduling.proto, menerapkan logika penegakan LM, dan menyediakan library klien sdv_service_bundles_scheduling. Definisi protobuf dan library platform
OEM (integrator sistem) Menentukan nilai konkret untuk setiap preset, seperti arti ELEVATED pada hardware tertentu, dan mengontrol konfigurasi seluruh sistem. /product/etc/lifecycle_config.textproto
Developer layanan Memilih nama preset logis yang sesuai dan mendaftarkan jalur scheduling_config.textproto dalam manifes paket layanan. scheduling_config.textproto dan sdv_service_bundles_manifest.textproto

Alur kerja teknis

  1. Integrasi platform: OEM menentukan lifecycle_config.textproto khusus kendaraan. File ini menetapkan profil penjadwalan (preset) di seluruh sistem dan memetakannya ke atribut penjadwalan Linux konkret berdasarkan hardware target.
  2. Pengembangan paket layanan: Developer menggabungkan scheduling_config.textproto dalam paket APEX mereka, merekomendasikan preset logis (misalnya, ELEVATED) dan menentukan nama thread internal.
  3. Integrasi paket layanan: Selama fase integrasi kendaraan, OEM meninjau preset yang direkomendasikan developer. OEM dapat mempertahankan profil yang direkomendasikan atau menggantinya, seperti mendowngrade layanan ELEVATED ke NORMAL, untuk meningkatkan stabilitas sistem secara keseluruhan sebelum menandatangani APEX.
  4. Penyelesaian atribut runtime: Saat layanan dimulai, LM mengidentifikasi preset yang diizinkan dari manifes layanan dan mengambil atribut Linux yang sesuai dari konfigurasi sistem OEM.
  5. Sinkronisasi dan penerapan saat startup: LM menerapkan atribut yang telah diselesaikan ke proses layanan sebelum memberi sinyal untuk melanjutkan eksekusi menggunakan protokol sinyal dan lanjutkan.

Konsep inti

Konsep berikut adalah inti dari framework penjadwalan SDV.

Preset penjadwalan

Preset penjadwalan adalah mekanisme utama untuk mengelola QoS di SDV. Daripada menentukan parameter penjadwalan Linux mentah, developer mereferensikan preset yang telah ditentukan sebelumnya berdasarkan nama. Pada waktu proses, LM memetakan nama logis ini ke atribut penjadwalan Linux yang konkret.

Preset berikut dikonfigurasi sebagai contoh di lifecycle_config.textproto:

Nama preset Kebijakan penjadwalan Nilai bagus standar Kasus penggunaan umum
NORMAL SCHED_OTHER 0 Layanan standar (HVAC, media, setelan)
ELEVATED SCHED_OTHER -10 Komponen dan infrastruktur sistem inti
IDLE SCHED_IDLE 19 Analisis latar belakang dan logging non-kritis
CUSTOM Ditentukan pengguna -20 (awal) Layanan yang memerlukan kebijakan atau afinitas real-time

Saat menerapkan preset, LM menggunakan panggilan sistem setpriority untuk menyetel nilai nice di seluruh proses. Hal ini memengaruhi pembagian CPU relatif yang diterima proses selama persaingan di bawah Completely Fair Scheduler (CFS) Linux default.

Hak istimewa dan keamanan

Untuk mencegah eskalasi prioritas yang tidak sah, platform SDV menggunakan model keamanan bertingkat berdasarkan domain SELinux dan kemampuan Linux.

Domain keamanan

  • untrusted_service_bundle: Domain default untuk preset standar (NORMAL, ELEVATED, IDLE). Kernel membatasi proses dalam domain ini, sehingga mencegahnya mengubah parameter penjadwalannya sendiri.
  • priority_service_bundle: Diberikan ke setiap paket layanan yang menggunakan preset dengan is_privileged: true ditetapkan di lifecycle_config.textproto seluruh sistem. Bertransisi ke domain ini memberikan kemampuan CAP_SYS_NICE kepada proses, sehingga memungkinkan proses mengelola alokasi resource-nya sendiri.

Kemampuan CAP_SYS_NICE

Platform memberikan kemampuan CAP_SYS_NICE ke proses di domain priority_service_bundle. Izin ini memungkinkan proses melakukan hal berikut:

  • Meningkatkan nilai nice-nya sendiri di luar tugas awalnya.
  • Ubah kebijakan penjadwalannya ke kelas real-time seperti SCHED_FIFO atau SCHED_RR.
  • Tetapkan afinitas CPU menggunakan sched_setaffinity.
  • Konfigurasi parameter batas waktu khusus untuk SCHED_DEADLINE.

Membatasi kemampuan ini ke domain khusus akan melindungi keseimbangan penjadwalan di seluruh sistem dengan membatasi gangguan pada layanan yang diberi otorisasi secara eksplisit.

Panduan konfigurasi

Bagian ini memberikan panduan konfigurasi untuk OEM dan developer layanan.

Panduan OEM: Preset di seluruh sistem

OEM menentukan profil penjadwalan di /product/etc/lifecycle_config.textproto. Platform ini memberikan contoh di lifecycle_management/config/lifecycle_config.textproto yang diharapkan disesuaikan oleh OEM berdasarkan hardware kendaraan.

Contoh: Menentukan preset real-time

OEM dapat menentukan preset CRITICAL untuk layanan terkait keselamatan yang tidak boleh pernah didahului oleh aplikasi standar:

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

Panduan developer: Konfigurasi paket layanan

Developer layanan merekomendasikan preset dan secara opsional menentukan nama thread logis dalam file scheduling_config.textproto. Agar dapat ditemukan oleh platform, jalur ke file ini harus didaftarkan di sdv_service_bundles_manifest.textproto.

Contoh: Pendaftaran manifes

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

Contoh: Menggunakan preset standar

Untuk sebagian besar layanan, merujuk nama preset di scheduling_config.textproto sudah cukup:

# configs/scheduling_config.textproto
scheduling_preset_name: "ELEVATED"

Contoh: Penjadwalan untuk thread pekerja yang dibuat layanan

Developer layanan dapat membuat thread worker tambahan dalam kodenya untuk menangani tugas khusus, seperti loop data sensor latensi rendah. Developer dapat menentukan atribut penjadwalan bernama untuk thread internal ini dalam file konfigurasi.

Gunakan aplikasi manual hanya di layanan istimewa yang menggunakan metadata ini untuk menetapkan properti bagi thread pekerja internalnya:

# 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
  }
}

Perilaku dan penegakan sistem

Platform SDV menggunakan model penerapan yang ketat untuk mengaktifkan konfigurasi penjadwalan sebelum menjalankan kode khusus layanan apa pun.

Sinkronisasi startup

Untuk mencegah layanan berjalan dengan prioritas yang salah (bahkan selama fase inisialisasi), LM dan Service Bundle Runner (SBR) menggunakan protokol sinkronisasi sinyal dan lanjutkan:

  1. Pembuatan proses: LM membuat proses SBR. Pada tahap ini, proses turunan SBR berjalan, tetapi langsung memasuki status diblokir, menunggu sinyal di stdin-nya.
  2. Penerapan atribut: Saat anak diblokir, LM menggunakan panggilan sistem setpriority untuk menerapkan nilai nice yang diminta dan mengonfigurasi kebijakan penjadwalan (misalnya, SCHED_IDLE).
  3. Transisi keamanan: LM melakukan transisi domain SELinux, memindahkan anak ke domain untrusted_service_bundle atau priority_service_bundle.
  4. Sinyal: Hanya setelah semua parameter berhasil diterapkan, LM akan mengirimkan sinyal satu byte ke stdin turunan.
  5. Eksekusi: SBR menerima sinyal dan mulai memuat library layanan serta memanggil metode siklus proses.

Dampak pada thread utama dan siklus proses

Dengan menyinkronkan sebelum memuat library layanan, platform mempertahankan prioritas yang diminta untuk thread eksekusi utama di semua callback siklus proses:

  • onCreate: Semua injeksi dependensi dan alokasi resource awal terjadi pada prioritas yang benar.
  • onStart: Preset mengatur transisi ke status aktif dan semua loop kerja awal.
  • onStop dan onDestroy: Platform melakukan operasi pembersihan dengan prioritas yang sama untuk mencegah aktivitas sistem penting terhenti selama penonaktifan.

Kumpulan thread Binder dan pewarisan prioritas

Thread di thread pool Binder yang dikelola platform tidak menjalankan pekerjaan dengan prioritas thread yang membuat pool. Sebagai gantinya, untuk transaksi sinkron, thread server mewarisi prioritas pemanggil. Driver kernel Binder mengontrol mekanisme pewarisan prioritas ini.

Penyesuaian tingkat rangkaian pesan

Paket layanan yang memerlukan kontrol terperinci (misalnya, loop pemrosesan real-time) harus menerapkan konfigurasi secara manual ke thread pekerja. Gunakan langkah-langkah berikut untuk menerapkan konfigurasi tingkat thread:

  1. Minta preset istimewa (dengan is_privileged: true ditetapkan).
  2. Gunakan fungsi get_scheduling_configuration dari library sdv_service_bundles_scheduling untuk membaca thread_scheduling_configuration.
  3. Terapkan atribut ke thread pekerja menggunakan sched_setattr.

Penerapan SELinux dan kemampuan

Platform ini menggunakan SELinux dan kemampuan Linux CAP_SYS_NICE untuk menerapkan preset penjadwalan:

  • Untuk layanan yang menggunakan preset seperti NORMAL atau IDLE, penjadwalan dikonfigurasi oleh LM selama startup. Layanan ini tidak memiliki kemampuan CAP_SYS_NICE dan tidak dapat mengubah prioritas atau kebijakannya.
  • Layanan yang menggunakan preset istimewa (is_privileged: true) diberi kemampuan CAP_SYS_NICE. Hal ini memungkinkan mereka mengontrol penjadwalan secara manual untuk thread internal mereka, sebagaimana diperlukan untuk tugas real-time.

Verifikasi dan contoh

Memverifikasi perilaku penjadwalan memerlukan kombinasi analisis log dan pengukuran performa tingkat sistem. Platform SDV menyediakan contoh khusus untuk mendemonstrasikan teknik ini.

Contoh penjadwalan QoS

Terletak di samples/qos_scheduling, contoh ini mencakup beberapa layanan pengujian performa yang dirancang untuk berjalan secara paralel dan melaporkan progresnya.

  • PerformanceTesterNormal: Berjalan dengan preset NORMAL.
  • PerformanceTesterElevated: Berjalan dengan preset ELEVATED.
  • PerformanceTesterRealtime: Menggunakan preset CUSTOM untuk menerapkan SCHED_FIFO ke thread pekerja internalnya.
  • PolicyOffender: Layanan diagnostik yang mencoba menyetel prioritas real-time saat menggunakan preset NORMAL. Hal ini digunakan untuk memverifikasi bahwa platform berhasil memblokir eskalasi yang tidak sah.

Menjalankan rangkaian verifikasi

  1. Aktifkan konfigurasi orkestrasi khusus QoS:

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

  2. Mulai ulang perangkat untuk memulai layanan di domain penjadwalan masing-masing:

    adb reboot

  3. Filter log untuk melihat hasil performa komparatif:

    adb logcat | grep sdv_sample_qos_common

    Layanan PerformanceTesterElevated melaporkan unit kerja yang diselesaikan secara signifikan lebih tinggi dibandingkan dengan PerformanceTesterNormal. Error penolakan EPERM atau SELinux disertakan dalam log untuk layanan PolicyOffender.

Kompatibilitas mundur

  • Untuk kompatibilitas mundur, setiap paket layanan lama yang menentukan scheduling_config_path dalam manifesnya, tetapi tidak menentukan scheduling_preset_name dalam file konfigurasi, akan otomatis diperlakukan sebagai layanan istimewa. Hal ini mempertahankan kemampuan yang diperlukan (misalnya, CAP_SYS_NICE) untuk layanan lama yang mengandalkan penyesuaian thread manual.
  • Pesan konfigurasi root DeadlineSchedulingConfiguration dijadwalkan untuk diganti namanya pada rilis mendatang. Nama saat ini bersifat historis dan tidak lagi secara akurat mencerminkan bahwa pesan tersebut menangani semua jenis penjadwalan, bukan hanya penjadwalan batas waktu.