Once per second, the recent CPU usage values for all threads are reduced. The recent CPU usage increases by 1 each time the thread is in control of the CPU at the end of a 10ms clock tick, up to a maximum value of 120. Is an integer that is calculated from the recent CPU usage of a thread. The nice value of a thread is set when the thread is created and is constant over the life of the thread, unless explicitly changed by the user via the renice The figure "How the Priority Value is Determined" illustrates some of the ways in which the priority value can change. Or renice command), and its CPU-usage penalty. Value (20 by default, optionally set by the nice The priority value of a fixed-priority thread is constant, while the priority value of a nonfixed priority thread is the sum of the minimum priority level for user threads When the scheduler is looking for a thread to dispatch, it chooses the dispatchable thread with the smallest priority value.Ī thread can be fixed-priority or nonfixed priority. That is, a smaller priority value indicates a more important thread. The priority value is a positive integer and varies inversely with the importance of the associated thread. The kernel maintains a priority value (sometimes termed the scheduling priority) for each thread. The following general discussion applies to both versions. The thread has the priority that would have been attributed to the process in Version 3.2.5. When fork() is called, a process and a thread to run in it are created. In AIX Version 4, process priority is simply a precursor to thread priority. The priority management tools in AIX Version 3.2.5 manipulate process priority. These applications might impose a lighter load on the system if converted to a multithread structure. Threads are primarily of interest for applications that currently consist of several asynchronous processes. The recalculation of the running thread's priority value at each clock interrupt means that a thread may lose control because its priority value has risen above that of another dispatchable thread. In AIX Version 4, this policy is defined to be equivalent to RR, except that it applies to threads with non-fixed priority. This policy is defined by POSIX1003.4a as implementation-defined. Only fixed-priority threads can have a RR scheduling policy. When a RR thread has control at the end of the time slice, it moves to the tail of the queue of dispatchable threads of its priority. This is similar to the AIX Version 3 scheduler round-robin scheme based on 10ms time slices. Only fixed-priority threads can have a FIFO scheduling policy. Once a thread with this policy is scheduled, it runs to completion unless it is blocked, it voluntarily yields control of the CPU, or a higher-priority thread becomes dispatchable. In AIX Version 4 there are three possible values for thread scheduling policy Scheduling Policy for Threads with Local or Global Contention Scope The algorithm for determining which thread should be run next is called a scheduling policy. The thread contends with the other threads within the process to be the recipient of the process's share of CPU time. (The thread that is created when a process is created has global contention scope.) If the contention scope is local, The thread contends for CPU time with all other threads in the system. They share the process's private segment and other resources.Ī user thread within a process has specified contention scope. When new or modified applications take advantage of AIX thread support to create additional threads, those threads are created within the context of the process. The process owns the resources used in execution the thread owns only its current state.
Each new process will be created with a single thread that has its parent process's priority and contends for the CPU with the threads of other processes. In fact, workloads migrated directly from earlier releases of AIX will create and manage processes as before. This does not mean that processes have ceased to exist.
The fundamental dispatchable entity of the AIX Version 4 scheduler is the thread.
It is a dispatchable entity that requires fewer resources to create than an AIX process. AIX Version 4 Thread SupportĬan be thought of as a low-overhead process. Although the net behavioral change for unchanged applications running on uniprocessors may be small, anyone concerned with performance tuning should understand the changes and the opportunities. Conceptually, the scheduling algorithm and priority scheme are similar to those of AIX Version 3.2.5, but the addition of thread support required many detail-level changes. The addition of thread support to AIX Version 4 has resulted in extensive changes to the CPU scheduler. Performance Overview of the AIX CPU SchedulerĪIX Versions 3.2 and 4 Performance Tuning Guide
0 kommentar(er)
