Realtime process management

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Reason: This article needs some language improvements, e.g do not use "You are whacked", describe the solution before and do not use casual language (Discuss in Talk:Realtime process management)

This article provides information on prioritizing process threads in real time, as opposed to at startup only. It shows how you can control CPU, memory, and other resource utilization of individual processes, or all processes run by a particular group.

While many recent processors are powerful enough to play a dozen video or audio streams simultaneously, it is still possible that another thread hijacks the processor for half a second to complete another task. This results in short interrupts in audio or video streams. It is also possible that video/audio streams get out of sync. While this is annoying for a casual music listener; for a content producer, composer or video editor this issue is much more serious as it interrupts their workflow.

The simple solution is to give the audio and video processes a higher priority. However, while normal users can set a higher nice value to a process, which means that its priority is lower, only root can set lower values and start processes at a lower nice value than 0. This protects the normal user from underpowering processes which are essential to the system. This can be especially important on multi-user machines.

Configuration

Real-time prioritizing is enabled by default on Arch Linux. System, group and user-wide configuration can be achieved using PAM and systemd.

The realtime package group provides additional tools to modify the realtime scheduling policies of IRQs and processes.

Note: When running a custom kernel, ensure it is PREEMPT enabled to make use of the methods mentioned above.

Configuring PAM

The /etc/security/limits.conf file provides configuration for the pam_limits PAM module, which sets limits on system resources (see limits.conf(5)).

Tip: It is advised to externalize the configuration of pam_limits to separate files below /etc/security/limits.d as those take precedence over the main configuration file.

There are two types of resource limits that pam_limits provides: hard limits and soft limits. Hard limits are set by root and enforced by the kernel, while soft limits may be configured by the user within the range allowed by the hard limits.

Installing the package realtime-privileges and adding the user to the realtime group, provides reasonable default values (e.g. relevant for Professional audio).

Configuring systemd services

Processes spawned by systemd system services need to specifically set up equivalents to limits.conf. Further information can be found in the sections systemd.exec(5) § CREDENTIALS and systemd.exec(5) § PROCESS PROPERTIES in systemd.exec(5).

Hard and soft realtime

Realtime is a synonym for a process which has the capability to run in time without being interrupted by any other process. However, cycles can occasionally be dropped despite this. Low power supply or a process with higher priority could be a potential cause. To solve this problem, there is a scaling of realtime quality. This article deals with soft realtime. Hard realtime is usually not so much desired as it is needed. An example could be made for car's ABS (anti-lock braking system). This can not be "rendered" and there is no second chance.

Power is nothing without control

The realtime-lsm module granted the right to get higher capabilities to users belonging to a certain UID. The rlimit way works similar, but it can be controlled graduated finer. There is a new functionality in PAM which can be used to control the capabilities on a per user or a per group level. In the current version (0.80-2) these values are not set correctly out of the box and still create problems. With PAM you can grant realtime priority to a certain user or to a certain user group. PAM's concept makes it imaginable that there will be ways in the future to grant rights on a per application level; however, this is not yet possible.

Tips and tricks

PAM-enabled login

See Start X at login.

For your system to use PAM limits settings you have to use a pam-enabled login method/manager. Nearly all graphical login managers are pam-enabled, and it now appears that the default Arch login is pam-enabled as well. You can confirm this by searching /etc/pam.d:

$ grep pam_limits.so /etc/pam.d/*

If you get nothing, you are whacked. But you will, as long as you have a login manager (and now PolicyKit). We want an output like this one:

/etc/pam.d/crond:session   required    pam_limits.so
/etc/pam.d/login:session		required	pam_limits.so
/etc/pam.d/polkit-1:session         required        pam_limits.so
/etc/pam.d/system-auth:session   required  pam_limits.so
/etc/pam.d/system-services:session   required    pam_limits.so

So we see that login, PolicyKit, and the others all require the pam_limits.so module. This is a good thing, and means PAM limits will be enforced.

Console/autologin

See: Automatically log in some user to a virtual console on startup

If you prefer to not have a graphical login, you still have a way. You need to edit the pam configuration for su (from coreutils):

/etc/pam.d/su

 ...
 session              required        pam_limits.so

See this forums post.