Качество планирования обслуживания в SDV

Система планирования качества обслуживания (QoS) SDV обеспечивает детерминированное распределение ресурсов ЦП для пакетов услуг, управляемых менеджером жизненного цикла (LM). Абстрагируя низкоуровневые атрибуты планирования Linux (политика, приоритет, Nice) в логические предустановки, платформа обеспечивает четкое разделение между разработкой услуг и настройкой системы в масштабах всего автомобиля. Это помогает обеспечить необходимую вычислительную пропускную способность для критически важных по безопасности и чувствительных ко времени рабочих нагрузок, в то время как система ограничивает фоновые задачи для предотвращения нестабильности.

Роли и обязанности

Модель планирования SDV основана на принципе делегирования ответственности, что помогает обеспечить переносимость сервисов, позволяя при этом производителю оборудования настраивать систему.

Технический рабочий процесс

1. Интеграция платформы: OEM-производитель определяет специфический для автомобиля файл lifecycle_config.textproto . Этот файл устанавливает общесистемные профили планирования (предустановки) и сопоставляет их с конкретными атрибутами планирования Linux на основе целевого оборудования.
2. Разработка пакета сервиса: разработчик включает файл scheduling_config.textproto в свой пакет APEX, рекомендуя логический параметр (например, ELEVATED ) и определяя любые внутренние имена потоков.
3. Интеграция пакета услуг: На этапе интеграции в автомобиль производитель оборудования проверяет рекомендованные разработчиком предустановки. Производитель оборудования может сохранить рекомендованный профиль или изменить его, например, понизить уровень услуги ELEVATED до NORMAL , чтобы повысить общую стабильность системы перед подписанием соглашения APEX.
4. Разрешение атрибутов во время выполнения: При запуске службы модуль управления службой (LM) определяет разрешенные предустановки в манифесте службы и извлекает соответствующие атрибуты Linux из системной конфигурации OEM-производителя.
5. Синхронизация и принудительное выполнение при запуске: LM применяет разрешенные атрибуты к процессу службы, прежде чем подать сигнал на продолжение выполнения с использованием протокола «сигнал-продолжение».

Основные концепции

Следующие концепции являются центральными для системы планирования SDV.

Предварительные настройки планирования

Предварительные настройки планирования являются основным механизмом управления качеством обслуживания (QoS) в SDV. Вместо определения прямых параметров планирования Linux разработчики ссылаются на предопределенные настройки по имени. Во время выполнения LM сопоставляет эти логические имена с конкретными атрибутами планирования Linux.

В качестве примера в lifecycle_config.textproto сконфигурированы следующие предустановки:

При применении предустановки LM использует системный вызов setpriority для установки общепроцессного значения nice . Это влияет на относительную долю ЦП, получаемую процессом во время конкуренции в рамках стандартного планировщика задач Linux Completely Fair Scheduler (CFS).

Привилегии и безопасность

Для предотвращения несанкционированного повышения приоритета платформа SDV использует многоуровневую модель безопасности, основанную на доменах SELinux и возможностях Linux.

Домены безопасности

• untrusted_service_bundle : Домен по умолчанию для стандартных предустановок ( NORMAL , ELEVATED , IDLE ). Ядро ограничивает процессы в этом домене, не позволяя им изменять собственные параметры планирования.
• priority_service_bundle : Предоставляется любому пакету служб, использующему предустановку, где is_privileged: true установлено в общесистемном файле lifecycle_config.textproto . Переход в этот домен предоставляет процессу возможность CAP_SYS_NICE , позволяя ему управлять собственным распределением ресурсов.

Возможность CAP_SYS_NICE

Платформа предоставляет процессам в домене priority_service_bundle возможность CAP_SYS_NICE . Это разрешение позволяет процессу выполнять следующие действия:

• Повысить его nice , выходя за рамки первоначального назначения.
• Измените политику планирования на использование классов реального времени, таких как SCHED_FIFO или SCHED_RR .
• Установите привязку ЦП с помощью sched_setaffinity .
• Настройте специализированные параметры крайнего срока для SCHED_DEADLINE .

Ограничение этой возможности выделенным доменом обеспечивает баланс планирования в масштабах всей системы, ограничивая сбои в работе явно авторизованных служб.

Руководство по настройке

В этом разделе представлены рекомендации по настройке как для производителей оборудования, так и для разработчиков сервисов.

Руководство OEM: общесистемные настройки

Производитель определяет профили планирования в /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"

Пример: Планирование рабочих потоков, создаваемых сервисом.

Разработчик сервиса может создать в своем коде дополнительные рабочие потоки для обработки специализированных задач, таких как цикл обработки данных с датчиков с низкой задержкой. Разработчик может определить именованные атрибуты планирования для этих внутренних потоков в файле конфигурации.

Использовать ручное применение только в привилегированных службах, которые используют эти метаданные для установки свойств своих внутренних рабочих потоков:

# 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 отправляет однобайтовый сигнал в stdin дочернего процесса.
5. Выполнение: SBR получает сигнал и начинает загрузку сервисных библиотек и вызов методов жизненного цикла.

Влияние на основной поток и жизненный цикл

Благодаря синхронизации перед загрузкой сервисных библиотек платформа поддерживает запрошенный приоритет для основного потока выполнения во всех обратных вызовах жизненного цикла:

• onCreate : Все процессы внедрения зависимостей и первоначального выделения ресурсов происходят с правильным приоритетом.
• onStart : Этот параметр определяет переход в активное состояние и начальные циклы работы.
• onStop и onDestroy : Платформа выполняет операции очистки с одинаковым приоритетом, чтобы предотвратить зависание критически важных системных процессов во время завершения работы.

Пул потоков Binder и наследование приоритетов

Потоки в управляемом платформой пуле потоков Binder не выполняют работу с приоритетом потока, создавшего пул. Вместо этого, для синхронных транзакций серверный поток наследует приоритет вызывающего потока. Этот механизм наследования приоритетов контролируется драйвером ядра Binder.

Тонкая настройка на уровне потоков

Для пакетов сервисов, требующих детального управления (например, циклов обработки в реальном времени), необходимо вручную применять конфигурации к рабочим потокам. Для применения конфигураций на уровне потоков выполните следующие действия:

1. Запросите привилегированный пресет (где is_privileged: true ).
2. Для чтения thread_scheduling_configuration используйте функцию get_scheduling_configuration из библиотеки sdv_service_bundles_scheduling .
3. Примените атрибуты к рабочим потокам с помощью sched_setattr .

SELinux и обеспечение соблюдения возможностей

Платформа использует SELinux и возможность Linux 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 . Текущее название является устаревшим и больше не отражает в полной мере, что сообщение обрабатывает все типы планирования, а не только планирование по крайним срокам.