Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 1. Before You Start Tuning Your Red Hat Enterprise Linux for Real Time System
Things to Remember While You Are Tuning Your Red Hat Enterprise Linux for Real Time Kernel
- Be PatientReal-time tuning is an iterative process; you will almost never be able to tweak a few variables and know that the change is the best that can be achieved. Be prepared to spend days or weeks narrowing down the set of tunings that work best for your system.Additionally, always make long test runs. Changing some tuning parameters then doing a five minute test run is not a good validation of a set of tunes. Make the length of your test runs adjustable and run them for longer than a few minutes. Try to narrow down to a few different tuning sets with test runs of a few hours, then run those sets for many hours or days at a time, to try and catch corner-cases of max latencies or resource exhaustion.
- Be AccurateBuild a measurement mechanism into your application, so that you can accurately gauge how a particular set of tuning changes affect the application's performance. Anecdotal evidence (for example, "The mouse moves more smoothly") is usually wrong and varies from person to person. Do hard measurements and record them for later analysis.
- Be MethodicalIt is very tempting to make multiple changes to tuning variables between test runs, but doing so means that you do not have a way to narrow down which tune affected your test results. Keep the tuning changes between test runs as small as you can.
- Be ConservativeIt is also tempting to make large changes when tuning, but it is almost always better to make incremental changes. You will find that working your way up from the lowest to highest priority values will yield better results in the long run.
- Be SmartUse the tools you have available. The Tuna graphical tuning tool makes it easy to change processor affinities for threads and interrupts, thread priorities and to isolate processors for application use. The
tasksetandchrtcommand line utilities allow you to do most of what Tuna does. If you run into performance problems, theftraceandperftools can help locate latency issues. - Be FlexibleRather than hard-coding values into your application, use external tools to change policy, priority and affinity. This allows you to try many different combinations and simplifies your logic. Once you have found some settings that give good results, you can either add them to your application, or set up some startup logic to implement the settings when the application starts.
Linux uses three main scheduling policies:
SCHED_OTHER(sometimes calledSCHED_NORMAL)- This is the default thread policy and has dynamic priority controlled by the kernel. The priority is changed based on thread activity. Threads with this policy are considered to have a real-time priority of 0 (zero).
SCHED_FIFO(First in, first out)- A real-time policy with a priority range of from 1 - 99, with 1 being the lowest and 99 the highest.
SCHED_FIFOthreads always have a higher priority thanSCHED_OTHERthreads (for example, aSCHED_FIFOthread with a priority of1will have a higher priority than anySCHED_OTHERthread). Any thread created as aSCHED_FIFOthread has a fixed priority and will run until it is blocked or preempted by a higher priority thread. SCHED_RR(Round-Robin)SCHED_RRis a modification ofSCHED_FIFO. Threads with the same priority have a quantum and are round-robin scheduled among all equal prioritySCHED_RRthreads. This policy is rarely used.
1.1. Running Latency Tests and Interpreting Their Results Link kopierenLink in die Zwischenablage kopiert!
1.1.1. Preliminary Steps Link kopierenLink in die Zwischenablage kopiert!
Procedure 1.1. To successfully test your system and interpret the results:
- Check the vendor documentation for any tuning steps required for low latency operation.This step aims to reduce or remove any System Management Interrupts (SMIs) that would transition the system into System Management Mode (SMM). While a system is in SMM it is running firmware and not running operating system code, meaning any timers that expire while in SMM will have to wait until the system transitions back into normal operation. This can cause unexplained latencies since SMIs cannot be blocked by Linux and the only indication that we actually took an SMI may be found in vendor-specific performance counter registers.
Warning
Red Hat strongly recommends that you do not completely disable SMIs, as it can result in catastrophic hardware failure. - Ensure that RHEL-RT and
rt-testspackage is installed.This step verifies that you have tuned the system properly. - Run the
hwlatdetectprogram.hwlatdetectlooks for hardware-firmware induced latencies by polling the clock-source and looking for unexplained gaps.Generally, you do not need to run any sort of load on the system while runninghwlatdetect, since the program is looking for latencies introduced by hardware architecture or BIOS/EFI firmware.A typical output ofhwlatdetectlooks like this:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The above result represents a system that was tuned to minimize system interruptions from firmware.However, not all systems can be tuned to minimize system interruptions as shown below:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The above result shows that while doing consecutive reads of the systemclocksource, there were 10 delays that showed up in the 15-18 us range.hwlatdetectwas using thetracermechanism as thedetectorfor unexplained latencies. Previous versions used a kernel module rather thanftrace tracer.parametersreport a latency and how the detection was run. The default latency threshold was 10 microseconds (10 us), the sample window was 1 second, the sampling window was 0.5 seconds.As a result,tracerran adetectorthread that ran for one half of each second of the specified duration.Thedetectorthread runs a loop which does the following pseudocode:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The inner loop comparison checks thatt0 - t1does not exceed the specified threshold (10 us default). The outer loop comparison checks the time between the bottom of the loop and the topt1 - t0. The time between consecutive reads of the timestamp register should be dozens of nanoseconds (essentially a register read, a comparison and a conditional jump) so any other delay between consecutive reads is introduced by firmware or by the way the system components were connected.Note
The values printed out by thehwlatdetectorforinnerandouterare the best case maximum latency. The latency values are the deltas between consecutive reads of the current systemclocksource(usually theTime Stamp CounterorTSCregister, but potentially theHPETorACPIpower management clock) and any delays between consecutive reads, introduced by the hardware-firmware combination.
1.1.2. Testing the System Real-time Performance under Load Link kopierenLink in die Zwischenablage kopiert!
rteval utility to test the system real-time performance under load. rteval starts a heavy system load of SCHED_OTHER tasks and then measures real-time response on each online CPU. The loads are a parallel make of the Linux kernel tree in a loop and the hackbench synthetic benchmark.
rteval then starts the cyclictest measurement program. This program starts the SCHED_FIFO real-time thread on each online core and then measures real-time scheduling response time. Each measurement thread takes a timestamp, sleeps for an interval, then takes another timestamp after waking up. The latency measured is t1 - (t0 + i), which is the difference between the actual wakeup time t1, and the theoretical wakeup time of the first timestamp t0 plus the sleep interval i.
rteval run are written to the XML file along with the boot log for the system. Then the rteval-<date>-N.tar.bz2 file is generated. N is a counter for the Nth run on <date>. A report, generated from the XML file, similar to the below, will be printed to the screen:
# rteval --summarize rteval-<date>-n.tar.bz2 command.