As per discussions in the SOAFEE SIG that SUSE is a founding member of, container users will be in need of running workloads with mixed criticality.
Maybe the easiest starting point will be allowing to assign containerized processes real-time priorities.
During last Hack Week, code review had confirmed no process priorities were being set in runc, but work towards experimental code changes got interrupted.
Goal for this Hackweek
Goal is to create a proof of concept where initially a hardcoded process priority gets assigned to a container (which would confirm we found the right place and have the needed capability permissions). This includes figuring out a development set-up for these container components. SUCCESS! Nice values such as -5 (range -20 to 19) could be assigned to a Tumbleweed container executed via podman on Tumbleweed x86_64, using a modified locally built and installed (PREFIX=/usr) runc binary in the initProcess code path.
Next step would be to alternatively assign a real-time process priority (different syscall and number range). SUCCESS! Among others, FIFO scheduler with real-time priority 42 (range 1 to 99) could be assigned to the Tumbleweed container's bash process.
A further step would be figuring out how to pass such meta information from container manifest through orchestrator to the runtime components, so that the priority does not need to be hardcoded and can be applied to one specific container only.
Out of scope will likely be investigating alternative container components, such as crun in place of runc.
It is understood real-time process priorities can be investigated on regular current Tumbleweed or SLE kernels, without requiring a SLERT kernel with PREEMPT_RT patchset specifically (although that would still be the deployment use case).
SUSE Labs Conference 2022 paper "SOAFEE: The quest for mixed criticality" by A. Färber, sections "Operating system and real-time" and "Kubernetes and real-time".
This project is part of:
Hack Week 22 Hack Week 21