Lập lịch chất lượng dịch vụ trong SDV

Khung lập lịch chất lượng dịch vụ (QoS) SDV cung cấp khả năng phân bổ tài nguyên CPU có tính xác định cho các gói dịch vụ do Trình quản lý vòng đời (LM) quản lý. Bằng cách trừu tượng hoá các thuộc tính lập lịch Linux cấp thấp (Chính sách, Mức độ ưu tiên, Nice) thành các chế độ đặt sẵn logic, nền tảng này cho phép tách biệt rõ ràng giữa quá trình phát triển dịch vụ và việc điều chỉnh hệ thống trên toàn bộ xe. Điều này giúp cung cấp băng thông tính toán cần thiết cho các khối lượng công việc quan trọng về độ an toàn và nhạy cảm về thời gian, trong khi hệ thống hạn chế các tác vụ ở chế độ nền để ngăn chặn tình trạng không ổn định.

Vai trò và trách nhiệm

Mô hình lập lịch SDV tuân theo một mẫu trách nhiệm được uỷ quyền để giúp đảm bảo các dịch vụ vẫn có thể di chuyển trong khi cho phép OEM điều chỉnh hệ thống.

Vai trò Trách nhiệm Sản phẩm chính
Nền tảng SDV (Google) Xác định giản đồ sdv_service_bundles_scheduling.proto, triển khai logic thực thi LM và cung cấp thư viện ứng dụng sdv_service_bundles_scheduling. Định nghĩa Protobuf và thư viện nền tảng
OEM (nhà tích hợp hệ thống) Xác định các giá trị cụ thể cho từng chế độ đặt sẵn, chẳng hạn như ý nghĩa của ELEVATED trên phần cứng cụ thể và kiểm soát cấu hình trên toàn hệ thống. /product/etc/lifecycle_config.textproto
Nhà phát triển dịch vụ Chọn tên đặt sẵn logic thích hợp và đăng ký đường dẫn scheduling_config.textproto trong tệp kê khai gói dịch vụ. scheduling_config.textprotosdv_service_bundles_manifest.textproto

Quy trình kỹ thuật

  1. Tích hợp nền tảng: OEM xác định lifecycle_config.textproto dành riêng cho xe. Tệp này thiết lập các hồ sơ lập lịch (giá trị đặt sẵn) trên toàn hệ thống và liên kết các hồ sơ đó với các thuộc tính lập lịch cụ thể của Linux dựa trên phần cứng mục tiêu.
  2. Phát triển gói dịch vụ: Nhà phát triển gói một scheduling_config.textproto trong gói APEX của họ, đề xuất một giá trị đặt sẵn logic (ví dụ: ELEVATED) và xác định mọi tên luồng nội bộ.
  3. Tích hợp gói dịch vụ: Trong giai đoạn tích hợp xe, OEM xem xét chế độ đặt sẵn mà nhà phát triển đề xuất. OEM có thể giữ lại hồ sơ được đề xuất hoặc ghi đè hồ sơ đó, chẳng hạn như hạ cấp dịch vụ ELEVATED xuống NORMAL để cải thiện độ ổn định tổng thể của hệ thống trước khi ký APEX.
  4. Phân giải thuộc tính thời gian chạy: Khi một dịch vụ được khởi động, LM sẽ xác định chế độ cài đặt sẵn được uỷ quyền từ tệp kê khai của dịch vụ và truy xuất các thuộc tính Linux tương ứng từ cấu hình hệ thống của OEM.
  5. Đồng bộ hoá và thực thi khi khởi động: LM áp dụng các thuộc tính đã phân giải cho quy trình dịch vụ trước khi báo hiệu để tiếp tục thực thi bằng giao thức báo hiệu và tiếp tục.

Các khái niệm chính

Các khái niệm sau đây là trọng tâm của khung lập lịch SDV.

Chế độ đặt sẵn để lên lịch

Các chế độ đặt sẵn về lập lịch là cơ chế chính để quản lý QoS trong SDV. Thay vì xác định các tham số lập lịch Linux thô, nhà phát triển tham chiếu các chế độ cài đặt sẵn được xác định trước theo tên. Trong thời gian chạy, LM sẽ ánh xạ các tên logic này đến các thuộc tính lập lịch biểu cụ thể của Linux.

Các chế độ đặt sẵn sau đây được định cấu hình làm ví dụ trong lifecycle_config.textproto:

Tên chế độ đặt sẵn Chính sách lập lịch Giá trị nice thông thường Trường hợp sử dụng điển hình
NORMAL SCHED_OTHER 0 Dịch vụ tiêu chuẩn (HVAC, nội dung nghe nhìn, chế độ cài đặt)
ELEVATED SCHED_OTHER -10 Cơ sở hạ tầng và các thành phần hệ thống cốt lõi
IDLE SCHED_IDLE 19 Số liệu phân tích trong nền và nhật ký không quan trọng
CUSTOM Do người dùng xác định -20 (ban đầu) Các dịch vụ yêu cầu chính sách hoặc mối quan hệ thân thiết theo thời gian thực

Khi áp dụng một chế độ cài đặt sẵn, LM sẽ sử dụng lệnh gọi hệ thống setpriority để đặt giá trị nice trên toàn bộ quy trình. Điều này ảnh hưởng đến tỷ lệ sử dụng CPU tương đối mà quy trình nhận được trong quá trình tranh chấp theo Bộ lập lịch hoàn toàn công bằng (CFS) mặc định của Linux.

Đặc quyền và bảo mật

Để ngăn chặn hành vi leo thang mức độ ưu tiên trái phép, nền tảng SDV sử dụng một mô hình bảo mật theo cấp dựa trên các miền SELinux và khả năng của Linux.

Miền bảo mật

  • untrusted_service_bundle: Miền mặc định cho các chế độ cài đặt sẵn tiêu chuẩn (NORMAL, ELEVATED, IDLE). Nhân hạn chế các quy trình trong miền này, ngăn chúng thay đổi các tham số lập lịch của chính mình.
  • priority_service_bundle: Được cấp cho mọi gói dịch vụ sử dụng một chế độ cài đặt sẵn mà is_privileged: true được đặt trong lifecycle_config.textproto trên toàn hệ thống. Việc chuyển sang miền này sẽ cấp cho quy trình khả năng CAP_SYS_NICE, cho phép quy trình quản lý việc phân bổ tài nguyên của riêng mình.

Quyền CAP_SYS_NICE

Nền tảng này cấp khả năng CAP_SYS_NICE cho các quy trình trong miền priority_service_bundle. Quyền này cho phép một quy trình thực hiện những việc sau:

  • Nâng giá trị nice của riêng nó lên cao hơn giá trị được chỉ định ban đầu.
  • Thay đổi chính sách lập lịch của lớp học thành các lớp học theo thời gian thực như SCHED_FIFO hoặc SCHED_RR.
  • Đặt mối liên kết CPU bằng cách sử dụng sched_setaffinity.
  • Định cấu hình các tham số thời hạn chuyên biệt cho SCHED_DEADLINE.

Việc hạn chế khả năng này trong một miền chuyên dụng sẽ bảo vệ sự cân bằng về lập lịch trên toàn hệ thống bằng cách hạn chế sự gián đoạn đối với các dịch vụ được uỷ quyền rõ ràng.

Hướng dẫn về cấu hình

Phần này cung cấp hướng dẫn về cấu hình cho cả OEM và nhà phát triển dịch vụ.

Hướng dẫn dành cho OEM: Giá trị đặt sẵn trên toàn hệ thống

OEM xác định các hồ sơ lập lịch trong /product/etc/lifecycle_config.textproto. Nền tảng này cung cấp một ví dụ tại lifecycle_management/config/lifecycle_config.textproto mà các nhà sản xuất thiết bị gốc dự kiến sẽ điều chỉnh dựa trên phần cứng của xe.

Ví dụ: Xác định chế độ đặt sẵn theo thời gian thực

Một OEM có thể xác định chế độ cài đặt sẵn CRITICAL cho các dịch vụ liên quan đến an toàn mà các ứng dụng tiêu chuẩn không bao giờ được phép chiếm quyền:

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

Hướng dẫn dành cho nhà phát triển: Cấu hình gói dịch vụ

Nhà phát triển dịch vụ nên đặt trước và có thể xác định tên luồng logic trong tệp scheduling_config.textproto. Để được nền tảng phát hiện, đường dẫn đến tệp này phải được đăng ký trong sdv_service_bundles_manifest.textproto.

Ví dụ: Đăng ký tệp kê khai

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

Ví dụ: Sử dụng chế độ đặt sẵn tiêu chuẩn

Đối với hầu hết các dịch vụ, việc tham chiếu tên đặt sẵn trong scheduling_config.textproto là đủ:

# configs/scheduling_config.textproto
scheduling_preset_name: "ELEVATED"

Ví dụ: Lập lịch cho các luồng trình chạy do dịch vụ tạo

Nhà phát triển dịch vụ có thể tạo thêm các luồng worker trong mã của họ để xử lý các tác vụ chuyên biệt, chẳng hạn như vòng lặp dữ liệu cảm biến có độ trễ thấp. Nhà phát triển có thể xác định các thuộc tính lập lịch có tên cho các luồng nội bộ này trong tệp cấu hình.

Chỉ sử dụng ứng dụng theo cách thủ công trong các dịch vụ đặc quyền sử dụng siêu dữ liệu này để đặt các thuộc tính cho luồng worker nội bộ của chúng:

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

Hành vi hệ thống và biện pháp thực thi

Nền tảng SDV sử dụng một mô hình thực thi nghiêm ngặt để kích hoạt các cấu hình lập lịch trước khi chạy bất kỳ mã dành riêng cho dịch vụ nào.

Đồng bộ hoá khi khởi động

Để ngăn một dịch vụ chạy ở mức độ ưu tiên không chính xác (ngay cả trong giai đoạn khởi tạo), LM và Service Bundle Runner (SBR) sẽ sử dụng giao thức đồng bộ hoá tín hiệu và tiếp tục:

  1. Tạo quy trình: LM phân nhánh quy trình SBR. Tại thời điểm này, quy trình con SBR đang chạy nhưng ngay lập tức chuyển sang trạng thái bị chặn, chờ tín hiệu trên stdin.
  2. Ứng dụng thuộc tính: Trong khi chặn tiến trình con, LM sẽ dùng lệnh gọi hệ thống setpriority để áp dụng giá trị nice được yêu cầu và định cấu hình chính sách lập lịch (ví dụ: SCHED_IDLE).
  3. Chuyển đổi bảo mật: LM thực hiện quá trình chuyển đổi miền SELinux, di chuyển phần tử con vào miền untrusted_service_bundle hoặc priority_service_bundle.
  4. Tín hiệu: Chỉ sau khi tất cả các tham số được áp dụng thành công, LM mới gửi tín hiệu một byte đến stdin của thành phần con.
  5. Thực thi: SBR nhận tín hiệu và bắt đầu tải các thư viện dịch vụ cũng như gọi các phương thức của vòng đời.

Tác động đến luồng chính và vòng đời

Bằng cách đồng bộ hoá trước khi tải các thư viện dịch vụ, nền tảng sẽ duy trì mức độ ưu tiên được yêu cầu cho luồng thực thi chính trên tất cả các lệnh gọi lại vòng đời:

  • onCreate: Tất cả hoạt động chèn phần phụ thuộc và phân bổ tài nguyên ban đầu đều diễn ra ở mức độ ưu tiên chính xác.
  • onStart: Chế độ cài đặt sẵn này chi phối quá trình chuyển đổi sang trạng thái hoạt động và mọi vòng lặp công việc ban đầu.
  • onStoponDestroy: Nền tảng thực hiện các thao tác dọn dẹp ở cùng mức độ ưu tiên để ngăn chặn các hoạt động quan trọng của hệ thống bị bỏ qua trong quá trình tắt.

Nhóm luồng liên kết và tính năng kế thừa mức độ ưu tiên

Các luồng trong nhóm luồng Binder do nền tảng quản lý không thực thi công việc với mức độ ưu tiên của luồng đã tạo nhóm. Thay vào đó, đối với các giao dịch đồng bộ, luồng máy chủ sẽ kế thừa mức độ ưu tiên của phương thức gọi. Trình điều khiển hạt nhân Binder kiểm soát cơ chế kế thừa mức độ ưu tiên này.

Tinh chỉnh ở cấp độ luồng

Các gói dịch vụ yêu cầu kiểm soát chi tiết (ví dụ: các vòng xử lý theo thời gian thực) phải áp dụng cấu hình theo cách thủ công cho các luồng worker. Hãy làm theo các bước sau để áp dụng cấu hình ở cấp độ luồng:

  1. Yêu cầu một chế độ đặt sẵn có đặc quyền (trong đó is_privileged: true được đặt).
  2. Dùng hàm get_scheduling_configuration trong thư viện sdv_service_bundles_scheduling để đọc thread_scheduling_configuration.
  3. Áp dụng các thuộc tính cho luồng worker bằng cách sử dụng sched_setattr.

Thực thi SELinux và các chức năng

Nền tảng này sử dụng SELinux và khả năng CAP_SYS_NICE của Linux để thực thi các chế độ đặt trước về lập lịch:

  • Đối với các dịch vụ sử dụng chế độ cài đặt sẵn như NORMAL hoặc IDLE, việc lập lịch được LM định cấu hình trong quá trình khởi động. Các dịch vụ này không có khả năng CAP_SYS_NICE và không thể thay đổi mức độ ưu tiên hoặc chính sách của chúng.
  • Các dịch vụ sử dụng chế độ cài đặt sẵn có đặc quyền (is_privileged: true) sẽ được cấp khả năng CAP_SYS_NICE. Điều này cho phép họ kiểm soát thủ công việc lập lịch cho các luồng nội bộ của mình, theo yêu cầu đối với các tác vụ theo thời gian thực.

Quy trình xác minh và mẫu

Để xác minh hành vi lập lịch, bạn cần kết hợp phân tích nhật ký và đo lường hiệu suất ở cấp hệ thống. Nền tảng SDV cung cấp một mẫu chuyên dụng để minh hoạ các kỹ thuật này.

Mẫu lập lịch QoS

Nằm trong samples/qos_scheduling, mẫu này bao gồm một số dịch vụ kiểm thử hiệu suất được thiết kế để chạy song song và báo cáo tiến trình của chúng.

  • PerformanceTesterNormal: Chạy với chế độ cài đặt sẵn NORMAL.
  • PerformanceTesterElevated: Chạy với chế độ cài đặt sẵn ELEVATED.
  • PerformanceTesterRealtime: Sử dụng chế độ cài đặt sẵn CUSTOM để áp dụng SCHED_FIFO cho các luồng worker nội bộ.
  • PolicyOffender: Một dịch vụ chẩn đoán cố gắng đặt mức độ ưu tiên theo thời gian thực trong khi sử dụng chế độ cài đặt sẵn NORMAL. Điều này dùng để xác minh rằng nền tảng chặn thành công hành vi leo thang trái phép.

Chạy bộ xác minh

  1. Bật cấu hình điều phối dành riêng cho QoS:

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

  2. Khởi động lại thiết bị để bắt đầu các dịch vụ trong miền lập lịch tương ứng:

    adb reboot

  3. Lọc nhật ký để xem kết quả hiệu suất so sánh:

    adb logcat | grep sdv_sample_qos_common

    Dịch vụ PerformanceTesterElevated báo cáo số lượng đơn vị công việc đã hoàn thành cao hơn đáng kể so với PerformanceTesterNormal. Lỗi EPERM hoặc lỗi từ chối SELinux có trong nhật ký của dịch vụ PolicyOffender.

Khả năng tương thích ngược

  • Để đảm bảo khả năng tương thích ngược, mọi gói dịch vụ cũ chỉ định scheduling_config_path trong tệp kê khai nhưng không chỉ định scheduling_preset_name trong tệp cấu hình sẽ tự động được coi là một dịch vụ đặc quyền. Điều này giúp duy trì các chức năng cần thiết (ví dụ: CAP_SYS_NICE) cho các dịch vụ cũ dựa vào việc điều chỉnh luồng thủ công.
  • Thông báo cấu hình gốc DeadlineSchedulingConfiguration dự kiến sẽ được đổi tên trong một bản phát hành trong tương lai. Tên hiện tại là tên cũ và không còn phản ánh chính xác rằng thông báo này xử lý tất cả các loại lịch biểu, chứ không chỉ lịch biểu thời hạn.