CPU Shielding capability

From eLinux.org
Jump to: navigation, search
CPU Shielding capability
Tim Bird, Sony Mobile
Selected to be sponsored by the CE Workgroup


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.

Related work

isolcpus=[KNL,SMP] Isolate CPUs from the general scheduler.
  <cpu number>,...,<cpu number>
  <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.



Contractor Candidates

None yet.


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)