การกำหนดเวลาคุณภาพของบริการใน SDV

เฟรมเวิร์กการจัดกำหนดการคุณภาพของการบริการ (QoS) ของ SDV จะจัดสรรทรัพยากร CPU ที่แน่นอนสำหรับชุดบริการที่จัดการโดย Lifecycle Manager (LM) การแยกแอตทริบิวต์การจัดกำหนดการ Linux ระดับต่ำ (นโยบาย ลำดับความสำคัญ Nice) ออกเป็นค่าที่กำหนดไว้ล่วงหน้าเชิงตรรกะทำให้แพลตฟอร์มสามารถแยกการพัฒนาบริการและการปรับแต่งระบบทั้งยานพาหนะได้อย่างชัดเจน ซึ่งจะช่วยให้แบนด์วิดท์ในการคำนวณที่จำเป็นสำหรับภาระงานที่สำคัญต่อความปลอดภัยและภาระงานที่คำนึงถึงเวลา ขณะที่ระบบจะจำกัดงานในเบื้องหลังเพื่อป้องกันไม่ให้เกิดความไม่เสถียร

บทบาทและความรับผิดชอบ

รูปแบบการกำหนดเวลา SDV เป็นไปตามรูปแบบความรับผิดที่ได้รับมอบหมายเพื่อให้มั่นใจว่าบริการจะยังคงพกพาได้ในขณะที่ OEM สามารถปรับแต่งระบบได้

บทบาท ความรับผิดชอบ ผลลัพธ์ที่สำคัญ
แพลตฟอร์ม SDV (Google) กำหนดสคีมา sdv_service_bundles_scheduling.proto, ใช้ตรรกะการบังคับใช้ LM และจัดเตรียมไลบรารีของไคลเอ็นต์ sdv_service_bundles_scheduling คำจำกัดความของ Protobuf และไลบรารีแพลตฟอร์ม
OEM (ผู้ผสานรวมระบบ) กำหนดค่าที่เฉพาะเจาะจงสำหรับค่าที่กำหนดล่วงหน้าแต่ละค่า เช่น ความหมายของ ELEVATED ในฮาร์ดแวร์ที่เฉพาะเจาะจง และควบคุมการกำหนดค่าทั้งระบบ /product/etc/lifecycle_config.textproto
นักพัฒนาบริการ เลือกชื่อค่าที่กำหนดล่วงหน้าเชิงตรรกะที่เหมาะสมและลงทะเบียนscheduling_config.textprotoเส้นทางในไฟล์ Manifest ของชุดบริการ scheduling_config.textproto และ sdv_service_bundles_manifest.textproto

เวิร์กโฟลว์ทางเทคนิค

  1. การผสานรวมแพลตฟอร์ม: OEM จะกำหนด lifecycle_config.textproto เฉพาะของยานพาหนะ ไฟล์นี้จะสร้างโปรไฟล์การจัดกำหนดการทั่วทั้งระบบ (ค่าที่กำหนดล่วงหน้า) และแมปกับแอตทริบิวต์การจัดกำหนดการ Linux ที่เฉพาะเจาะจงตามฮาร์ดแวร์เป้าหมาย
  2. การพัฒนาชุดบริการ: นักพัฒนาแอปจะรวม scheduling_config.textproto ไว้ในแพ็กเกจ APEX โดยแนะนำค่าที่กำหนดไว้ล่วงหน้าเชิงตรรกะ (เช่น ELEVATED) และกำหนดชื่อเธรดภายใน
  3. การผสานรวมแพ็กเกจบริการ: ในช่วงการผสานรวมยานพาหนะ OEM จะตรวจสอบค่าที่กำหนดล่วงหน้าที่นักพัฒนาแอปแนะนำ OEM สามารถเก็บโปรไฟล์ที่แนะนำไว้หรือลบล้างได้ เช่น ดาวน์เกรดบริการ ELEVATED เป็น NORMAL เพื่อปรับปรุงความเสถียรโดยรวมของระบบก่อนลงนามใน APEX
  4. การแก้ไขแอตทริบิวต์รันไทม์: เมื่อเริ่มบริการ LM จะระบุค่าที่กำหนดล่วงหน้าที่ได้รับอนุญาตจากไฟล์ Manifest ของบริการ และดึงแอตทริบิวต์ Linux ที่เกี่ยวข้องจากการกำหนดค่าระบบของ OEM
  5. การซิงค์และการบังคับใช้เมื่อเริ่มต้น: LM จะใช้แอตทริบิวต์ที่แก้ไขแล้วกับกระบวนการบริการก่อนที่จะส่งสัญญาณให้ดำเนินการต่อโดยใช้โปรโตคอลสัญญาณและดำเนินการต่อ

แนวคิดหลัก

แนวคิดต่อไปนี้เป็นหัวใจสำคัญของเฟรมเวิร์กการจัดตารางเวลา SDV

การกำหนดเวลาที่ตั้งไว้ล่วงหน้า

ค่าที่กำหนดล่วงหน้าสำหรับการตั้งเวลาเป็นกลไกหลักในการจัดการ QoS ใน SDV นักพัฒนาแอปจะอ้างอิงค่าที่กำหนดไว้ล่วงหน้าตามชื่อแทนที่จะกำหนดพารามิเตอร์การจัดกำหนดการ Linux ดิบ ในเวลาที่รันไทม์ LM จะแมปชื่อเชิงตรรกะเหล่านี้กับแอตทริบิวต์การจัดกำหนดการ Linux ที่เฉพาะเจาะจง

ค่าที่กำหนดล่วงหน้าต่อไปนี้ได้รับการกำหนดค่าเป็นตัวอย่างใน lifecycle_config.textproto

ชื่อค่าที่กำหนดล่วงหน้า นโยบายการกำหนดเวลา ค่า Nice ปกติ กรณีการใช้งานทั่วไป
NORMAL SCHED_OTHER 0 บริการมาตรฐาน (HVAC, สื่อ, การตั้งค่า)
ELEVATED SCHED_OTHER -10 คอมโพเนนต์และโครงสร้างพื้นฐานของระบบหลัก
IDLE SCHED_IDLE 19 ข้อมูลวิเคราะห์เบื้องหลังและการบันทึกที่ไม่สำคัญ
CUSTOM ผู้ใช้กำหนด -20 (เริ่มต้น) บริการที่ต้องใช้นโยบายหรือความสัมพันธ์แบบเรียลไทม์

เมื่อใช้ค่าที่กำหนดไว้ล่วงหน้า LM จะใช้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
  • ตั้งค่าความสัมพันธ์ของ CPU โดยใช้ sched_setaffinity
  • กำหนดค่าพารามิเตอร์กำหนดเวลาเฉพาะสำหรับ 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

ตัวอย่าง: การลงทะเบียนไฟล์ Manifest

# 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 ที่สร้างขึ้นจากบริการ

นักพัฒนาบริการอาจสร้างเธรด Worker เพิ่มเติมในโค้ดเพื่อ จัดการงานเฉพาะทาง เช่น ลูปข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองต่ำ นักพัฒนาซอฟต์แวร์ สามารถกำหนดแอตทริบิวต์การจัดกำหนดการที่มีชื่อสำหรับเธรดภายในเหล่านี้ใน ไฟล์การกำหนดค่าได้

ใช้การสมัครด้วยตนเองเฉพาะในบริการที่มีสิทธิ์ซึ่งใช้ข้อมูลเมตานี้เพื่อตั้งค่าพร็อพเพอร์ตี้สำหรับเธรดของ Worker ภายใน

# 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. การใช้แอตทริบิวต์: ขณะที่บล็อกไคลเอ็นต์ LM จะใช้การเรียกของระบบ setpriority เพื่อใช้ค่า nice ที่ขอและกำหนดค่านโยบายการจัดกำหนดการ (เช่น SCHED_IDLE)
  3. การเปลี่ยนความปลอดภัย: LM จะทำการเปลี่ยนโดเมน SELinux โดยย้ายกระบวนการย่อยไปยังโดเมน untrusted_service_bundle หรือ priority_service_bundle
  4. สัญญาณ: หลังจากใช้พารามิเตอร์ทั้งหมดเรียบร้อยแล้วเท่านั้น LM จะส่งสัญญาณ 1 ไบต์ไปยัง stdin ของเด็ก
  5. การดำเนินการ: SBR จะได้รับสัญญาณและเริ่มโหลดไลบรารีบริการและเรียกเมธอดวงจร

ผลกระทบต่อชุดข้อความหลักและวงจร

การซิงค์ก่อนโหลดไลบรารีบริการจะช่วยให้แพลตฟอร์มรักษาระดับความสำคัญที่ขอสำหรับเธรดการดำเนินการหลักใน Callback ของวงจรทั้งหมดได้

  • onCreate: การแทรกทรัพยากร Dependency ทั้งหมดและการจัดสรรทรัพยากรเริ่มต้นจะเกิดขึ้นตามลำดับความสำคัญที่ถูกต้อง
  • onStart: ค่าที่กำหนดล่วงหน้าจะควบคุมการเปลี่ยนไปเป็นสถานะที่ใช้งานอยู่และลูปการทำงานเริ่มต้น
  • onStop และ onDestroy: แพลตฟอร์มจะดำเนินการล้างข้อมูลที่ลำดับความสำคัญเดียวกันเพื่อป้องกันไม่ให้กิจกรรมของระบบที่สำคัญหยุดชะงักระหว่างการปิดระบบ

กลุ่มเทรด Binder และการรับค่าลำดับความสำคัญ

เธรดใน Thread Pool ของ Binder ที่แพลตฟอร์มจัดการจะไม่ดำเนินการที่มีลำดับความสำคัญของเธรดที่สร้างพูล แต่สำหรับธุรกรรมแบบซิงโครนัส เธรดเซิร์ฟเวอร์จะรับช่วงลำดับความสำคัญของผู้เรียกใช้ ไดรเวอร์เคอร์เนลของ Binder จะควบคุมกลไกการรับช่วงลำดับความสำคัญนี้

การปรับแต่งระดับชุดข้อความ

แพ็กเกจบริการที่ต้องมีการควบคุมแบบละเอียด (เช่น ลูปการประมวลผลแบบเรียลไทม์) ต้องใช้การกำหนดค่ากับเธรดของ Worker ด้วยตนเอง ทำตามขั้นตอนต่อไปนี้เพื่อใช้การกำหนดค่าระดับเธรด

  1. ขอค่าที่กำหนดล่วงหน้าที่มีสิทธิ์ (ที่ตั้งค่า is_privileged: true ไว้)
  2. ใช้ฟังก์ชัน get_scheduling_configuration จากไลบรารี sdv_service_bundles_scheduling เพื่ออ่าน thread_scheduling_configuration
  3. ใช้แอตทริบิวต์กับ Worker Thread โดยใช้ sched_setattr

การบังคับใช้ SELinux และความสามารถ

แพลตฟอร์มใช้ SELinux และCAP_SYS_NICEความสามารถของ Linux เพื่อบังคับใช้ค่าที่กำหนดไว้ล่วงหน้าในการจัดกำหนดการ

  • สำหรับบริการที่ใช้ค่าที่กำหนดไว้ล่วงหน้า เช่น 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 กับเธรดของ Worker ภายใน
  • 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 Denial จะรวมอยู่ในบันทึกของบริการ PolicyOffender

ความเข้ากันได้แบบย้อนหลัง

  • เพื่อความเข้ากันได้แบบย้อนหลัง ระบบจะถือว่าแพ็กเกจบริการเดิมที่ระบุ scheduling_config_path ในไฟล์ Manifest แต่ไม่ได้ระบุ scheduling_preset_name ในไฟล์กำหนดค่าเป็นบริการที่มีสิทธิ์โดยอัตโนมัติ ซึ่งจะรักษาความสามารถที่จำเป็น (เช่น CAP_SYS_NICE) สำหรับบริการรุ่นเก่าที่ต้องอาศัยการปรับแต่งเธรดด้วยตนเอง
  • เรามีกำหนดที่จะเปลี่ยนชื่อข้อความการกำหนดค่ารูท DeadlineSchedulingConfiguration ในรุ่นต่อๆ ไป ชื่อปัจจุบันเป็นชื่อเดิมและไม่ได้แสดงอย่างถูกต้องอีกต่อไปว่าข้อความนี้จัดการการกำหนดเวลาทุกประเภท ไม่ใช่แค่การกำหนดเวลาตามกำหนดเวลา