Python low-latency contour: RT mechanisms, WCET and measurement instead of a 0.5 ms guarantee

Что подтверждают Linux и CPython

• PREEMPT_RT делает большую часть kernel execution preemptible, использует priority inheritance и threaded interrupts и тем самым уменьшает источники scheduling latency. Это механизм RT-платформы, а не сертификат конкретного application deadline.
• SCHED_FIFO и SCHED_DEADLINE — реальные scheduler policies. Для SCHED_DEADLINE hard schedulability привязана к task model, WCET/runtime, deadline, period и admission/schedulability conditions.
• nohz_full, CPU affinity/isolation и IRQ placement могут уменьшать OS jitter, но имеют preconditions и tradeoffs и должны проверяться на конкретном host.
• Memory locking полезен для снижения риска page-fault latency; Linux RT monitors отдельно отслеживают page faults у real-time tasks.
• CPython shared memory может убрать сериализацию и лишнее копирование между процессами. Это performance primitive, а не автоматическая atomicity/process-safety или deadline guarantee.
• Обычный GIL-enabled CPython сериализует исполнение Python bytecode между threads; process separation или bounded native code могут уменьшить этот bottleneck. Free-threaded builds существуют, но не являются универсальной заменой измерению worst-case latency.

Как обращаться с целью 0.5 ms

0.5 ms is a benchmark target, not a guaranteed deadline. Сначала необходимо определить, что именно считается heartbeat/deadline: wakeup-to-run, один compute cycle, IPC round trip, end-to-end market-data decision path или другая величина.

После этого измеряется не только median/average. Нужны tail latency, worst observed misses, duration теста, load profile и причины выбросов. Для ОС Linux предоставляет RTLA/timerlat и osnoise-инструменты; firmware/hardware noise также надо измерять отдельно, потому что некоторые задержки возникают вне контроля обычного scheduler path.

Scheduler policy не заменяет WCET и admission evidence

SCHED_DEADLINE управляется параметрами runtime/deadline/period. Для hard schedulability runtime должен покрывать worst-case execution time соответствующей задачи, а workload должен пройти feasibility/admission constraints. Поэтому запись «включить SCHED_DEADLINE и получить гарантированное выполнение» некорректна без связанного WCET и system-level schedulability evidence.

SCHED_FIFO также требует осторожности: runaway high-priority work способен вытеснить обычные задачи и повредить доступности системы. RT policy выбирается из модели workload и failure behavior, а не из общего рейтинга «FIFO сначала, DEADLINE оптимально».

Python hot path: что можно оптимизировать

• разделить orchestration/control plane и ограниченный latency-sensitive worker;
• минимизировать allocations и непредсказуемые операции в измеряемом участке;
• использовать shared memory там, где это действительно уменьшает serialization/copy cost, отдельно проектируя synchronization и memory ordering;
• выносить строго bounded compute в native extension только после профилирования и с явной ownership/error boundary;
• управлять cyclic GC только если объектная модель и lifecycle это допускают; gc.disable()/gc.freeze() — runtime tools, не доказательство deadline;
• memory locking, CPU isolation, IRQ affinity и timer coalescing/slack считать tuning hypotheses и проверять по одной с rollback.

Что нужно, чтобы превратить target в поддерживаемое утверждение

1. точные CPU, firmware, kernel version/config и PREEMPT state;
2. точный Python build, native modules и dependency set;
3. формальное определение workload/deadline и допустимого miss policy;
4. WCET или консервативная execution-time bound для admitted hot path;
5. scheduler parameters и admission/schedulability result;
6. длительное измерение under representative load: distribution, tail и deadline misses;
7. RTLA/osnoise + hardware-noise evidence и page-fault/allocation/GC telemetry;
8. rollback/fail-safe behavior при нарушении latency assumptions.

Без такого пакета корректная формулировка — low-latency architecture candidate, а не hard-real-time certification.