IBM REDP-4285-00 Manual De Usuario
Chapter 4. Tuning the operating system
109
Draft Document for Review May 4, 2007 11:35 am
4285ch04.fm
4.4.1 Tuning process priority
As we stated in 1.1.4, “Process priority and nice level” on page 5, it is not possible to change
the process priority of a process. This is only indirectly possible through the use of the nice
level of the process, but even this is not always possible. If a process is running too slowly,
you can assign more CPU to it by giving it a lower nice level. Of course, this means that all
other programs will have fewer processor cycles and will run more slowly.
the process priority of a process. This is only indirectly possible through the use of the nice
level of the process, but even this is not always possible. If a process is running too slowly,
you can assign more CPU to it by giving it a lower nice level. Of course, this means that all
other programs will have fewer processor cycles and will run more slowly.
Linux supports nice levels from 19 (lowest priority) to -20 (highest priority). The default value
is 0. To change the nice level of a program to a negative number (which makes it higher
priority), it is necessary to log on or su to root.
is 0. To change the nice level of a program to a negative number (which makes it higher
priority), it is necessary to log on or su to root.
To start the program xyz with a nice level of -5, issue the command:
nice -n -5 xyz
To change the nice level of a program already running, issue the command:
renice level pid
To change the priority of a program with a PID of 2500 to a nice level of 10, issue:
renice 10 2500
4.4.2 CPU affinity for interrupt handling
Two principles have proven to be most efficient when it comes to interrupt handling (refer to
1.1.6, “Interrupt handling” on page 6 for a review of interrupt handling):
1.1.6, “Interrupt handling” on page 6 for a review of interrupt handling):
Bind processes that cause a significant amount of interrupts to a CPU.
CPU affinity enables the system administrator to bind interrupts to a group or a single
physical processor (of course, this does not apply on a single-CPU system). To change
the affinity of any given IRQ, go into /proc/irq/%{number of respective irq}/ and
change the CPU mask stored in the file smp_affinity. To set the affinity of IRQ 19 to the
third CPU in a system (without SMT) use the command in Example 4-6.
physical processor (of course, this does not apply on a single-CPU system). To change
the affinity of any given IRQ, go into /proc/irq/%{number of respective irq}/ and
change the CPU mask stored in the file smp_affinity. To set the affinity of IRQ 19 to the
third CPU in a system (without SMT) use the command in Example 4-6.
Example 4-6 Setting the CPU affinity for interrupts
[root@linux /]#echo 03 > /proc/irq/19/smp_affinity
Let physical processors handle interrupts.
In symmetric multithreading (SMT) systems such as IBM POWER 5+ processors
supporting multi threading, it is suggested that you bind interrupt handling to the physical
processor rather than the SMT instance. The physical processors usually have the lower
CPU numbering so in a two-way system with multi threading enabled, CPU ID 0 and 2
would refer to the physical CPU, and 1 and 3 would refer to the multi threading instances.
If you do not use the smp_affinity flag, you will not have to worry about this.
supporting multi threading, it is suggested that you bind interrupt handling to the physical
processor rather than the SMT instance. The physical processors usually have the lower
CPU numbering so in a two-way system with multi threading enabled, CPU ID 0 and 2
would refer to the physical CPU, and 1 and 3 would refer to the multi threading instances.
If you do not use the smp_affinity flag, you will not have to worry about this.
4.4.3 Considerations for NUMA systems
Non-Uniform Memory Architecture (NUMA) systems are gaining market share and are seen
as the natural evolution of classic symmetric multiprocessor systems. Although the CPU
scheduler used by current Linux distributions is well suited for NUMA systems, applications
might not always be. Bottlenecks caused by a non-NUMA-aware application can cause
performance degradations that are hard to identify. The recent numastat utility shipped in the
as the natural evolution of classic symmetric multiprocessor systems. Although the CPU
scheduler used by current Linux distributions is well suited for NUMA systems, applications
might not always be. Bottlenecks caused by a non-NUMA-aware application can cause
performance degradations that are hard to identify. The recent numastat utility shipped in the
numactl
package helps to identify processes that have difficulties dealing with NUMA
architectures.