Linux process Management (ii) Scheduling of processes and resource constraints

1 Process scheduling
The most important feature of the readiness process is that the process is non-blocking. The process of user interaction, large volumes of Read and write files, response to I/O, and network events can take a significant amount of time to wait for resources to be available and cannot be turned into a ready state for a long time (long relative to the instruction run time), so the readiness process should first be non-blocking. A ready process must also have at least some "time slices" (the scheduler is assigned to the process's run time). The kernel maintains all the ready processes with a ready queue, and once a process consumes its time slices, the kernel moves them out of the queue until all the ready processes consume the time slices to consider putting them back into the queue.
Multitasking operating systems are divided into two main categories: collaborative and preemptive. Linux implements the latter form of multitasking, and the scheduler can require one process to stop running and the processor to run another process. The behavior of this abort-running process is called preemption, and, similarly, the time that the process runs before being preempted is called the process time slice (named after a small piece of time that the scheduler assigns to each ready process).
In a co-multitasking system, a process continues to run until it stops spontaneously. We call the process spontaneous stop behavior for surrender. Ideally, process yields will occur frequently, but the operating system must not be forced to make a surrender. As a result, a botched or corrupt program can run for a long time, even causing the entire system to die. For this reason, almost all modern operating systems employ a preemptive multitasking mechanism, and Linux is no exception.
The Linux scheduling algorithm employs a preemptive multitasking mechanism that supports features such as multiprocessor, processor affinity, non-uniform Memory access (NUMA), real-time processes, and user-defined priorities.

Time slices. If the time slice is too long, the process must wait for a long time to run, which reduces the parallelism of the operation, and the user perceives a noticeable delay; on the contrary, the time slice is too short, a lot of time is spent on the process scheduling, and the time locality of the program cannot be guaranteed. Linux is expected to do its best in both ways by dynamically allocating process time slices.
The process does not have to consume all the time slices in a single run. A process that is assigned a 100ms time slice may run 20ms because it is blocked by waiting for resources such as keyboard input. At this point, the scheduler temporarily moves the process out of the ready queue, and when the resource is available, in this case the keyboard buffer is not empty and the scheduler wakes up the process. The process will continue to run, consuming the remaining 80ms or blocking again.

The process of continuously consuming all available time slices is called the processor constraint process. Such processes crave CPU time and consume the entire time allocated by the scheduler. The simplest examples are infinite loops, and other examples include scientific computation, mathematical calculus, and image processing.
Most of the time a process that waits for a blocking state of a resource is called an I/O constrained process. The I/O constrained process often initiates and waits for file I/O, blocks the keyboard input, or the user moves the mouse. Examples of I/O blockers include file utilities such as CP or MV, which do almost nothing in addition to requesting the kernel to perform I/O operations, including GUI applications, most of which are waiting for user input.

When a process consumes time slices, the scheduler aborts its operation and starts running a new process. If there is no other ready process, the kernel will give all elapsed time slices of the process new time slices, continue to run. While the process is running, if another high-priority process is ready (perhaps before this process is blocked on the keyboard input, the user just typed a word), the current running process is directly aborted and switched to the high-priority process. Therefore, there is no higher priority process that is ready but not running, and the running process in the system must be the highest-priority, running process. Ensure that the top priority runs in the ready queue.

A thread is a running unit in a process, and all processes have at least one thread. Each line routine alone occupies a virtual processor: The individual register group, the instruction counter, and the processor state. Although most processes have only one thread, the process can actually have many threads, each of which accomplishes different tasks, but shares the same address space (that is, the same dynamic memory, mapping files, target code, and so on), open file queues, and other kernel resources. The kernel simplifies threading to the process of sharing resources, which means that the kernel simplifies two threads in a process into two different processes that share a series of kernel resources (address space, open file list, and so on).

2 Yield processor
Generally, UNIX programs tend to use event-driven mechanisms built on a block-based file descriptor. When process Io is blocked, the kernel will preempt the processor without requiring the process to explicitly yield the processor. Linux is a preemptive multitasking operating system with little chance of reasonable use of Sched_yield (), but it also provides a system tune to allow the process to voluntarily yield the processor. The kernel is fully capable of making optimal and efficient scheduling decisions because the kernel is clearly more qualified than a standalone application to decide when to preempt which process, and two different mechanisms for multitasking and preemptive multitasking come from a different understanding of this.
When a thread tries to request a lock that another thread already owns, the thread needs to explicitly let the processor out until the lock is available. This method is the simplest and most efficient when the kernel does not support user space locks. However, the modern Linux threading implementation (the New POSIX threading Library,or NPTL) ushered in an optimization scheme based on a fast user mutex that provides support for user space locks in the kernel.
After version 2.6, the actual effect of calling Sched_yield () is the same as the process consuming time slice, which differs from the processing of the earlier kernel, when Sched_yield () has a slight effect and has a ping-pong problem.

3 Process Priority
int Nice (int inc);
Nice value [-20, 19], the default value is 0,nice value the higher the priority, the longer the time slice. When running a process, the Linux scheduler always prioritizes high-priority threads. Non-root users can use only positive Inc to lower the priority level.

int getpriority (int which, int who);
int setpriority (int which, int who, int prio);
which specifies that the action object is a process, a process group, or a user, who specifies the corresponding ID, which represents the current action object at 0. Like nice, non-root users can use only positive Inc to lower their priority.

int ioprio_get (int which, int who)
int ioprio_set (int which, int. who, int Ioprio)
By default, the I/O scheduler determines I/O priorities with process-friendliness, so setting priorities automatically alters I/O priority. As a complement to process prioritization, Linux also allows processes to specify I/O precedence, and the kernel I/O scheduler always prioritizes requests from high I/O priorities.

4 Processor Affinity
Symmetric multiprocessor SMP refers to the pooling of a set of processors (multiple CPUs) on a single computer, the sharing of memory subsystems between CPUs and the bus structure, controlled by an operating system. The system distributes the task queue symmetrically over multiple CPUs, which greatly improves the data processing capability of the whole system. All processors have equal access to memory, I/O, and external interrupts. In a symmetric multiprocessor system, the system resources are shared by all CPUs in the system, and the workloads are evenly distributed across all available processors. Generally speaking, the SMP structure of the machine scalability is poor, it is difficult to do more than 100 multiprocessor, the general is generally 8 to 16. The SMP system has basic requirements for hardware:
1. The internal APIC (Advanced Programmable Interrupt Controllers) unit must be built into the CPU. The core of the Intel Multi-processing specification is the use of Advanced Programmable Interrupt controllers (Programmable Interrupt controllers--apics). The CPU communicates between them by sending interrupts to each other. By giving the interrupt additional actions (actions), different CPUs can control each other to some degree. Each CPU has its own APIC (the local APIC of that CPU), and there is an I/O APIC to handle interrupts caused by I/O devices, the I/O APIC is installed on the motherboard, but the APIC on each CPU is indispensable, Otherwise, you will not be able to handle interrupt coordination between multiple CPUs.
2, the same product model, the same type of CPU core. For example, although Athlon and Pentium III each have a APIC unit built in, it is impossible to make them work together to build an SMP system, and of course, even Celeron and Pentium III, the likelihood is 0, Even the Coppermine core Pentium III and Tualatin's Pentium III also fail to establish SMP systems--because their run instructions are not identical and the APIC interrupt coordination varies greatly.
3. The exact same operating frequency. If you want to establish a dual Pentium III system, you must have two 866MHz or two 1000MHz processors, you can not use a 866MHz, another 1000MHz to build, otherwise the system will not be lit normally.
4. Keep the same product serial number as possible. Even the same core of the same frequency processor can cause incredible problems due to the different production batches. Two production batches of CPUs run as a dual processor, it is possible that a CPU burden is too high, while the other burden of a small situation, unable to maximize performance, and worse, may lead to the crash, therefore, should choose the same batch of processors to build the SMP system.

On symmetric multiprocessor (SMP), the process scheduler must decide which process to run on each CPU, so there are two issues that must be resolved: The scheduler must take full advantage of the system's processor and try to avoid processor idle. However, if a process has been running on a CPU, the process scheduler should also put it on the same CPU as much as possible, because the process migration between processors can result in a performance penalty. The greatest performance loss comes from the caching effect of the migration. In the design of modern SMP systems, each processor's cache is independent, that is, the processor does not share the data in the cache.
Deciding when to move processes to avoid imbalances, called load balancing, is critical to the performance of SMP machines. Processor affinity indicates the likelihood that a process stays on the same processor. The term "soft affinity" (soft affinity) indicates the natural tendency of the scheduler to continuously dispatch processes to the same processor. The Linux scheduler does this as much as possible, considering the migration process only when the load is extremely unbalanced.
However, there are times when a user or application needs to secure a binding between the process and the processor, which typically occurs when the process relies heavily on caching and expects to stay on the same processor. The term hard affinity affinity describes forcing the kernel to guarantee the process-to-processor binding. The process inherits processor affinity from the parent process, which, by default, may run on any CPU. Linux provides two system calls to get and set the hard affinity of the process:
int sched_setaffinity (pid_t pid, size_t setsize, const cpu_set_t set);
int sched_getaffinity (pid_t pid, size_t setsize, const cpu_set_t set);

5 Real-time systems
If a system is governed by the minimum amount of time between the request and the response and the number of commands, the system is said to be "live". Real-time system is divided into two kinds of soft and hard real-time system. Hard real-time systems are very strict in terms of operating deadlines, which can lead to failures over time and serious consequences. On the other hand, the soft real-time system does not think that exceeding the deadline is a serious failure. Hard real-time systems are easy to distinguish: anti-lock systems, military weapons systems, medical devices, signal processing are more typical examples. Soft real-time system is not easy to distinguish, a more obvious example is the video processing program: If the operating time limit is exceeded, the user will notice some quality degradation, but a small amount of frame loss can be tolerated.

The scheduling behavior of Linux depends on the scheduling policy of the process, also called the scheduling category. Linux provides two types of real-time scheduling policies as a complement to the normal default policy. The predetermined macros in header file <sched.h> represents each policy: SCHED_FIFO,SCHED_RR and Sched_other, respectively. Each process has a static priority that is not related to the nice value, a value of 0 for a normal program, and 1 to 99 for a real-time program. The Linux scheduler always chooses the highest-priority process to run (the process with the largest number of static precedence).
1, "FIFO" strategy: FIFO policy is a very simple real-time strategy without time slices. As long as there is no superior
First-level processes are ready, and the FIFO type process will continue to run. In particular, once the FIFO class process is ready, it will directly preempt the normal process. The FIFO process continues to run until it blocks or calls Sched_yield (), or the high-priority process is ready. When a FIFO process is blocked, the scheduler moves it out of the ready queue.
2, the rotation strategy, similar to the FIFO type, only introduces additional rules for processing the same priority process, expressed as SCHED_RR. RR-type time slices are only relevant across processes of the same priority.
3, General scheduling policy, Sched_other represents the standard scheduling policy, applicable to the default non-real-time process. All of these processes have a static priority of 0, so any ready FIFO or RR-shaped process will preempt them.
4, Batch scheduling policy, Sched_batch is the policy of batch scheduling or idle scheduling, it is in some way the opposite of real-time scheduling: This type of process will only run when there is no other ready process in the system, even if those processes have consumed the time slice.

System calls related to process scheduling:
int sched_get_priority_min (int policy);
int Sched_get_priority_max (int policy);
int Sched_getparam (pid_t pid, struct sched_param sp);
int Sched_setparam (pid_t pid, const struct Sched_param sp);
int Sched_rr_get_interval (pid_t pid, struct timespec *tp);

Real-time processes are happy to see certainty. In real-time calculations, if the same input is given, an action always produces the same result at the same time, we say that the action is deterministic. Modern computers can be said to be an indeterminate set of aggregates: multi-level caching (unpredictable hits or not), multiprocessor, paging, swapping, and multitasking all make it impossible to estimate how long an action takes. Deterministic real-time applications generally try to limit unpredictability and worst-case latencies. There are two ways to achieve a goal.
1, data failure prediction and memory locking, for paging and switching to the real-time process of uncertainty, "by locking" or "hard connection" to the address space in advance to put the page in physical memory, prevent it from being swapped out. Once the page is locked, the kernel will not be swapped out, no access will cause page faults, and most real-time applications will lock some and all of the pages to physical memory.
2,CPU Affinity and real-time processes, the second difficulty in real-time applications is multitasking. Although the Linux kernel is preemptive, the scheduler does not always dispatch another process directly. Sometimes, the current process runs in a critical section of the kernel, and the scheduler must wait for it to exit the critical section, and if there is a real-time process to run, the delay will be unacceptable and will soon exceed the operating period. As a result, multitasking and paging also bring similar uncertainties. The same is true for multi-tasking solutions: eliminate it. If you have more than one processor in your system, you can specify one or more dedicated to the real-time process. In practical terms, you separate the real-time process from the multitasking. One potential optimization for real-time processes is to keep one processor for each real-time process, and the remaining processors are shared by other processes.

6 Resource limits
The Linux kernel has resource constraints on the process, which explicitly specifies the maximum amount of kernel resources the process can consume, such as the number of open files, memory pages, unhandled signals, and so on. The limit is mandatory and the kernel does not allow the process to exceed this hard limit. The structure defines two caps: soft limit and hard limit. The kernel enforces soft limits on processes, but the process itself can modify the soft limit, which can be any value between 0 and hard limits. Processes that do not have cap_sys_resource capabilities (for example, non-root processes) can only reduce the hard limit. A non-privileged program cannot raise a hard limit, including reverting to a higher value before, and therefore, lowering the hard limit is irreversible. A privileged process can set a hard limit to any legal value. Currently, Linux offers 15 resource limits:
Resourcelimit Softlimit Hardlimit Comments
Rlimit_as rlim_infinity rlim_infinity process address space limit
Rlimit_core 0 rlim_infinity coredump File maximum value
RLIMIT_CPU rlim_infinity rlim_infinity Process maximum CPU time
Rlimit_data rlim_infinity rlim_infinity process data segment and heap size
Rlimit_fsize rlim_infinity rlim_infinity the largest file created
Rlimit_locks rlim_infinity rlim_infinity Maximum number of file locks
Rlimit_memlock 8Pages 8Pages memory lock Max bytes
Rlimit_msgqueue 800KB 800KB Maximum allocated space in Message Queuing
Rlimit_nice 0 0 The maximum value of the bottom nice value (elevation priority)
Rlimit_nofile 1024 1024 The maximum number of files that can be opened
Rlimit_nproc 0 (impliesnolimit) 0 (impliesnolimit) system maximum number of processes allowed at any time
Rlimit_rss rlim_infinity The maximum number of pages that the rlim_infinity process can reside in memory
Rlimit_rtprio 0 0 Maximum real-time priority
Rlimit_sigpending 0 0 Maximum number of signals in a user message queue
Rlimit_stack maximum byte length of the 8MB rlim_infinity stack

Linux process Management (ii) Scheduling of processes and resource constraints