CPU Shielding capability
- CPU Shielding capability
- Tim Bird, Sony Mobile
In multi-processor realtime systems, it is sometimes desirable to isolate some CPUs in the system to enhance their capability to maintain realtime performance.
Normally, when the Linux kernel is running in an SMP configuration, any CPU may take an interrupt or run a process. Under realtime conditions, the operations of scheduling multiple processes or handling an interrupt may interfere with a particular process meeting it's realtime deadlines.
It would be nice to be able to isolate a realtime process on a CPU such that it was shielded from the scheduling of other processes and from handling interrupts.
This project would create a new 'shield' command, which would restrict a particular CPU to execution of an particular process (or set of processes), and also prevent that CPU from handling interrupts. This might involve modifying the kernel scheduler and using IRQ affinity features in the kernel to achieve this result.
cgroups supports such a feature, called 'cpusets', but if the feature can be provided outside of cgroups, that would be better, since cgroups is generally incompatible with realtime embedded Linux.
- RedHawk Linux has a command called 'shield' which performs this function:
- isolcpus on kernel command line
- from Documentation/kernel-parameters.txt:
isolcpus=[KNL,SMP] Isolate CPUs from the general scheduler. Format: <cpu number>,...,<cpu number> or <cpu number>-<cpu number> (must be a positive range in ascending order) or a mixture <cpu number>,...,<cpu number>-<cpu number> This option can be used to specify one or more CPUs to isolate from the general SMP balancing and scheduling algorithms. You can move a process onto or off an "isolated" CPU via the CPU affinity syscalls or cpuset. <cpu number> begins at 0 and the maximum value is "number of CPUs in system - 1". This option is the preferred way to isolate CPUs. The alternative -- manually setting the CPU mask of all tasks in the system -- can cause problems and suboptimal load balancer performance.
What is isolcpus missing, in order for it to fulfill the needed functionality?
If cgroups had less overhead, would that be sufficient for this feature?
Does the feature need to be configurable at runtime? (isolcpus is at boot time)