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.
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)).
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 setup 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 login 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.