Difference between revisions of "Realtime process management"
m (added classes and priority sections, added kernel documention to ext links)
m (added links to sysstat home, askapache article, kernel docss)
|Line 104:||Line 104:|
Revision as of 03:25, 6 August 2010
- 1 Realtime for Normal users
- 2 Realtime and Realtime is not the same
- 3 A Small History to Understand The Problem
- 4 Power is Nothing without Control
- 5 The necessary settings for realtime
- 6 PAM-enabled Login
- 7 Scheduling Policies
- 8 Scheduling Classes
- 9 Applications
- 10 External Links
Realtime for Normal users
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 multiuser machines.
Realtime and Realtime is not the same
Realtime is a synonym for a process which has as much capabilities to run in time without being interrupted by any other process. A couple of things can make it drop cycles nevertheless. Maybe the processor is running out of juice or another process with an even higher priority steals too many CPU-cycles. There is a scaling of realtime quality. The main aspect we are dealing with is the soft realtime. If a box runs out of power and the video editor's playback starts to drop frames, the process must be made different like rendering out the preview file so that it can be played without problems. Hard realtime is usually not "desired" but "needed". An example could be made for car's ABS. This can not be "rendered" and there is no second chance.
A Small History to Understand The Problem
There have always been efforts to make it easier for the user to achieve realtime capabilities from the kernel. A lot of patches were floating around the web. As of generation 2.6 there was an addon module available called realtime-lsm. It required CAPABILITY build as module and was only to handle by the more experienced user since the absence of CAPABILITY in the kernel in case that neither capability nor realtime-lsm was loaded can cause trouble.  As of kernel-2.6.12, the so called rlimits patch has been accepted in the mainstream kernel and is now the desired way to provide normal users with realtime capabilities.
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. But this is not yet possible.
The necessary settings for realtime
First of all, make sure your kernel is compiled with "preemptible kernel" settings. As /boot/kconfig26 tells you, the standard Arch Linux kernel is configured that way. This warning just goes out to all the selfcompilers. Secondly, you need a PAM>0.80 or 0.79-3(that was patched). The last I can confirm working was 0.80-2 from "testing". Just note that the names for the variables in limits.conf have changed from 0.79 to 0.80! Now edit your /etc/security/limits.conf. Arch Linux comes with sane standards for users from the @audio group. Make sure that you are a member of it and you are mainly done. The standard settings are enough to get jack-server running with hydrogen or ardour. For some other applications it might be necessary to redefine the values for rt_prio from 65 to 80 or even higher!
The following settings work for me also with ardour:
@audio - rtprio 70 @audio - memlock 250000
See: Start X at Boot
To activate the settings in /etc/security/limits.conf you have to use a PAM-enabled login method/manager. Nearly all graphical login managers are pam-enabled. You can check that by looking for the related line/file in /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). The line we are looking for is:
session required pam_limits.so
See: Automatic VC Login
If you prefer to not have a graphical login, you still have a way. You need to edit the pam stuff for su (from coreutils):
# /etc/pam.d/su ... session required pam_limits.so
Source (thanks to jochen and dunc): http://bbs.archlinux.org/viewtopic.php?pid=387214
CFS implements three scheduling policies:
- SCHED_NORMAL (traditionally called SCHED_OTHER)
- The scheduling policy that is used for regular tasks.
- Does not preempt nearly as often as regular tasks would, thereby allowing tasks to run longer and make better use of caches but at the cost of interactivity. This is well suited for batch jobs.
- This is even weaker than nice 19, but its not a true idle timer scheduler in order to avoid to get into priority inversion problems which would deadlock the machine.
- This is the realtime io class. The RT scheduling class is given first access to the disk, regardless of what else is going on in the system. Thus the RT class needs to be used with some care, as it can starve other processes. As with the best effort class, 8 priority levels are defined denoting how big a time slice a given process will receive on each scheduling window. This scheduling class is given higher priority than any other in the system, processes from this class are given first access to the disk every time. Thus it needs to be used with some care, one io RT process can starve the entire system. Within the RT class, there are 8 levels of class data that determine exactly how much time this process needs the disk for on each service. In the future this might change to be more directly mappable to performance, by passing in a wanted data rate instead.
- This is the best-effort scheduling class, which is the default for any process that hasn’t set a specific io priority. This is the default scheduling class for any process that hasn’t asked for a specific io priority. Programs inherit the CPU nice setting for io priorities. This class takes a priority argument from 0-7, with lower number being higher priority. Programs running at the same best effort priority are served in a round-robin fashion. The class data determines how much io bandwidth the process will get, it’s directly mappable to the cpu nice levels just more coarsely implemented. 0 is the highest BE prio level, 7 is the lowest. The mapping between cpu nice level and io nice level is determined as: io_nice = (cpu_nice + 20) / 5.
- This is the idle scheduling class, processes running at this level only get io time when no one else needs the disk. A program running with idle io priority will only get disk time when no other program has asked for disk io for a defined grace period. The impact of idle io processes on normal system activity should be zero. This scheduling class does not take a priority argument. The idle class has no class data, since it doesn’t really apply here.
See: Pro Audio