Shulou(Shulou.com)05/31 Report--

This article will explain in detail what are the differences between NI and PR about the process priority of Linux. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Why should there be process priority?

This doesn't seem to be explained too much. after all, since the birth of the multitasking operating system, the ability of process execution to occupy cpu has been something that must be artificially controlled. Because some processes are relatively important, while others are less important.

The way process priority works is basically unchanged since it was invented. Whether it is the era of only one cpu or the era of multicore cpu, it is achieved by controlling how long the process takes up cpu.

That is to say, in the same scheduling cycle, high-priority processes take longer, while low-priority processes take less time.

Please don't confuse these two concepts in the system: nice (NI) and priority (PR). They are inextricably linked, but for the current Linux system, they are not the same concept.

Let's look at this order:

Do you really understand the difference between the specific meaning of PRI column and NI column?

Similarly, if it is the top command:

Do you understand the difference between PR value and Ni value? If not, then we can first figure out what the nice value is.

What is the NICE value?

The NICE value should be a concept well known to those familiar with Linux/UNIX. It is a value that reflects the "priority" status of a process, ranging from-20 to 19, with a total of 40 levels.

The smaller the value, the higher the "priority" of the process, and the higher the value, the lower the "priority".

For example, we can use the NICE command to set the nice value of a bash command to be executed by:

[root@zorrozou-pc0 zorro] # nice-n 10 bash

So I open another bash with a nice value of 10, and by default, the priority of the process should be inherited from the parent process, which is usually 0.

We can view the nice value of the current shell directly through the nice command:

[root@zorrozou-pc0 zorro] # nice 10

Compare the normal situation:

[root@zorrozou-pc0 zorro] # exit

Exit the bash with the current nice value of 10, open a normal bash, and check its Nice value:

[root@zorrozou-pc0 zorro] # bash [root@zorrozou-pc0 zorro] # nice 0

In addition, you can use the renice command to adjust the nice value of a running process, and we can also use commands such as top and ps to check the nice value of the process. I won't say much about the specific method, and you can refer to the relevant man page.

It is important to note that I am using the term nice value here instead of priority.

The nice value is not priority, but it does affect the priority of the process.

In English, if we describe a person as nice, it generally means that he or she is more popular. What kind of people have a good relationship? They tend to be modest and polite people.

For example, if you go to lunch with a nice person and order two identical meals, after serving one, the nice person will usually say, "you eat first!" Oh, this is popular, this guy nice! But if the other one is late, then the nice man will be hungry.

What does that mean?

The more nice people have, the worse their ability to seize resources, while the less nice people have, the stronger their ability to seize resources. This is what the nice value means. The lower the nice value, the less nice the process, the stronger the ability to preempt cpu and the higher the priority (the author's explanation is so vivid that the editor can't help but like it manually!).

On the Linux that used to use O1 scheduling, we will also call the nice value static priority, which is basically in line with the characteristics of the nice value, that is, when the nice value is set, it will not change unless we use renice to change it.

The value of priority changes on the previous kernel O1 scheduler, so it is also called dynamic priority.

What are priorities and real-time processes?

Let's take a look at what the priori value is, which is the PRI value seen in the ps command or the PR value seen in the top command.

In this paper, in order to distinguish these concepts, later:

The nice value is uniformly used to represent the Ni value, or static priority, which is adjusted by the nice and renice commands.

The practical priority value represents the PRI and PR values, or dynamic priority.

We also uniformly define the concept of "priority" as the meaning of priority value.

In the kernel, the value range of process priority is defined by a macro whose name is MAX_PRIO and its value is 140.

This value is composed of two other values, one is the NICE_ WIDTH macro that represents the range of nice values, and the other is the MAX_RT_PRIO macro that represents the priority range of the real-time process (realtime).

To put it bluntly, Linux actually implements a range of 140 priorities, ranging from 0 to 139. the smaller the value, the higher the priority. Nice values range from-20 to 19, and the mapping to the actual priority range is 100-139.

The default priority of the newly generated process is defined as:

# define DEFAULT_PRIO (MAX_RT_PRIO + NICE_WIDTH / 2)

It actually corresponds to 0 of the nice value.

Normally, the priority of any process is this value, even if we adjust the priority of the process through the nice and renice commands, its value range will not exceed the range of 100139, unless the process is a real-time process, then its priority value will become one of the range of 0-99.

An implicit message here is that the current Linux is an operating system that already supports real-time processes.

What is a real-time operating system?

We will not explain its meaning and its application in industry in detail here. If you are interested, you can refer to Wikipedia of the real-time operating system.

To put it simply, the real-time operating system needs to ensure that the relevant real-time processes respond in a short time, do not have a long delay, and require minimum interrupt delay and process switching delay.

For such requirements, the general process scheduling algorithms, whether O1 or CFS, are unable to meet, so when the kernel is designed, the real-time process is mapped to 100priorities, these priorities are higher than the normal process priority (nice value), and the real-time process scheduling algorithm is also different, they use a simpler scheduling algorithm to reduce scheduling overhead.

In general, processes running in Linux systems can be divided into two categories:

Real-time process

Non real-time process

The main difference between them is by priority.

All priority values in the range of 0-99 are real-time processes, so this priority range can also be called real-time process priority, while those in the range of 100-139 are non-real-time processes.

In the system, you can use the chrt command to view and set the real-time priority status of a process. Let's first take a look at the use of the chrt command:

If we first look at the Policy options section shown, we will find that the system provides five scheduling strategies for various processes.

But what is not stated here is that these five scheduling strategies are for two kinds of processes respectively. For real-time processes, the available scheduling strategies are: SCHED_FIFO, SCHED_RR, and for non-real-time processes: SCHED_OTHER, SCHED_OTHER, SCHED_IDLE.

The overall priority strategy of the system is:

If there is a real-time process that needs to be executed in the system, the real-time process is given priority.

The execution of non-real-time processes will not be scheduled until the real-time process exits or actively gives up the CPU.

A real-time process can specify a priority range of 1-99, and the method for a program to be executed in real time is:

[root@zorrozou-pc0 zorro] # chrt 10 bash [root@zorrozou-pc0 zorro] # chrt-p $$pid 14840s current scheduling policy: SCHED_RR pid 14840s current scheduling priority: 10

As you can see, the newly opened bash is already a real-time process, with a default scheduling policy of SCHED_RR and a priority of 10. If you want to modify the scheduling policy, add a parameter:

[root@zorrozou-pc0 zorro] # chrt-f 10 bash [root@zorrozou-pc0 zorro] # chrt-p $$pid 14843s current scheduling policy: SCHED_FIFO pid 14843s current scheduling priority: 10

As mentioned earlier, both SCHED_RR and SCHED_FIFO are real-time scheduling policies that can only be set for real-time processes. For all real-time processes, high-priority (that is, low-priority) processes must be guaranteed to execute ahead of low-priority processes.

The scheduling policy of SCHED_RR and SCHED_FIFO only works when the priority of two real-time processes is the same, and the difference is as the name implies:

SCHED_FIFO

It is scheduled on a first-in-first-out queue. In the case of the same priority, whoever executes first will schedule first, unless it exits or actively releases CPU.

SCHED_RR

Multiple processes with the same priority are processed in the way of time slice rotation. The length of time slice is 100ms.

This is Linux's description of the priority of real-time processes and related scheduling algorithms. The whole is simple and practical.

Relatively more troublesome are non-real-time processes, which are the main categories of processes on Linux. For the processing of non-real-time process priorities, first of all, we would like to introduce their related scheduling algorithms: O1 and CFS.

What is O1 scheduling?

The O1 scheduling algorithm was introduced in Linux 2.6, and after Linux 2.6.23, the kernel replaced the scheduling algorithm with CFS.

Although O1 algorithm is no longer the default scheduling algorithm used by the current kernel, but since a large number of online servers may still use the old version of Linux, I believe many servers are still using O1 scheduler, so it makes sense to briefly explain this scheduler with a little breath.

The name of this scheduler is O1 mainly because the time complexity of its algorithm is O1.

The O1 scheduler is still designed according to the classical idea of time slice allocation.

To put it simply, the idea of a time slice is to divide the execution time of CPU into a small section, if it is a 5ms section. So if multiple processes want to execute at the same time, in fact, each process takes turns to occupy the cpu time of 5ms, and from the time scale of 1s, these processes are executed "at the same time".

Of course, for a multi-core system, you just have to do this for each core. In this case, how can priorities be supported?

In fact, time slices are allocated into several kinds of different sizes, high-priority processes use large time slices, and low-priority processes use small time slices. In this way, after the speed of a cycle, the process with high priority will take up more time and get special treatment.

Another special feature of O1 algorithm is that even processes with the same nice value will be divided into two types according to their CPU usage: CPU consumption and IO consumption.

The characteristic of a typical CPU consuming process is that it always takes up CPU for operations, and the time slices allocated to it are always exhausted before the program can be scheduled.

For example, a variety of common arithmetic programs.

The characteristic of IO consumption is that it often releases CPU on its own initiative without running out of time slices.

Editors such as vi,emacs are typical IO consumptive processes.

Why make such a distinction? Because IO consuming processes are often processes that interact with people, such as shell, editors, and so on.

When there are both such processes and CPU consumptive processes in the system, and their nice values are the same, assuming that they are given the same length of time slices, all of them are 500ms, then the human operation may become stuttered because the CPU consumptive process has been occupying CPU.

As you can imagine, when bash waits for input, it does not occupy CPU, and the program consumed by CPU will operate all the time, assuming that each time it is assigned to a time slice of 500ms, and when a person types a character on bash, then bash will probably have to wait for a few hundred ms to give a response, because when people type in characters, the time slices of other processes are probably not exhausted, so the system will not schedule the bash level for processing.

In order to improve the response speed of IO consuming processes, the system will distinguish between these two types of processes, and dynamically adjust CPU consuming processes to lower their priority, while IO consuming processes will increase their priority to reduce the actual length of time slices of CPU consuming processes.

The known range of nice values is-20-19, and the range of priori values is 100-139. for a process with a default nice value of 0, the initial priority value should be 120. as it continues to execute, the kernel will observe the CPU consumption state of the process and dynamically adjust the priority value, with an adjustable range of +-5.

That is, the * priority can be automatically adjusted to 115 and 125. This is why the nice value is called static priority, while the priority value is called dynamic priority. However, this dynamic adjustment function is not needed after the scheduler is changed to CFS, because CFS changes to a different way of CPU time allocation, which we will talk about later.

What is CFS completely fair scheduling?

O1 is already the previous generation scheduler. Because of its poor support for multi-core and multi-CPU systems and the addition of cgroup in kernel functions, Linux began to enable CFS as a general priority (SCHED_OTHER) process scheduling method after 2.6.23.

In this redesigned scheduler, the concepts of time slices, dynamic and static priorities, and IO consumption, CPU consumption are no longer important. CFS adopts a new way to support the above functions.

The basic idea of its design is: we want to implement a scheduler that is completely fair to all processes.

It's the same old question: how to be completely fair? The answer is similar to the idea of CFQ in the previous IO scheduling article:

If there are currently n processes to be scheduled for execution, the scheduler should schedule and execute all the n processes within a relatively small time range, and divide the cpu time equally, so that all processes can be scheduled fairly.

Then this relatively small time is the delay time that any R-state process is scheduled, that is, any R-state process must be scheduled within this time range. This time can also be called a scheduling cycle, and its English name is: sched_latency_ns.

Priority of CFS

Of course, priorities also need to be supported in CFS. In the new system, priority is determined by the speed of time consumption (vruntime growth).

That is to say, for CFS, the absolute value of time accumulation measured is the same as recorded in vruntime, but the growth rate of different priority process time is different, the growth rate of high priority process time is slow, and the growth rate of low priority time is fast.

For example, if a process with a priority of 19 actually takes up 1 second of cpu, then 1 second is recorded in vruntime. But if it is a process with a priority of-20, it is likely to actually take up 10s in CPU, and only 1s will be recorded in vruntime.

The cpu time consumption ratio of different nice values implemented by CFS is set in the kernel according to the principle of "about 10% of the time difference per difference level of cpu".

The general idea here is that if two processes with a nice value of 0 occupy 50% of the cpu at the same time, they should each account for 50% of the cpu. If the nice value of one of the processes is adjusted to 1, then the high-priority process should take up 10% more cpu than the lower one, that is, 55% of the processes with a nice value of 0 and 45% of the processes with a nice value of 1. Then they take up 55:45 of cpu time.

The proportion of this value is about 1.25. That is, the difference in the proportion of cpu elapsed time between two adjacent nice values should be about 1.25. According to this principle, the kernel corresponds to the time calculation ratio of 40 nice values, which exist as an array in the kernel:

What is the multi-CPU CFS scheduling like?

In the above description, we can assume that there is only one CPU in the system, then there is only one associated scheduling queue.

The reality is that the system has multiple cores or even multiple CPU. CFS has considered this situation from the very beginning. It maintains a scheduling queue for each CPU core, so that each CPU can schedule its own queue process.

This is also the fundamental reason why CFS is more efficient than O1 scheduling algorithm: one queue per CPU can avoid using large kernel locks on global queues, thus improving parallel efficiency.

Of course, the most direct impact is that the load between CPU may be uneven. In order to maintain load balance between CPU, CFS has to load balance all CPU periodically, so it is possible for processes to switch on scheduling queues of different CPU.

This process also requires locking the relevant CPU queues, thus reducing the parallelism caused by multiple running queues.

Overall, however, CFS's parallel queuing approach is more efficient than O1's global queuing approach. Especially when there are more and more CPU cores, the efficiency of global locking decreases significantly.

The purpose of the editor is to start from the priority of the Linux system process, we also made a more in-depth analysis of the CFS scheduling algorithm. In my experience, this knowledge is very useful for us to observe the state of the system and related optimizations.

For example, what exactly do the NI and PR values mean when using the top command? There are also similarities between the NI and PRI values in the ps command, the difference between the-e and-r parameters of the ulimit command, and so on. Of course, I hope that after reading this article, I can give you a deeper understanding of the display of these commands.

In addition, we will find that although the PR value in the top command has the same meaning as the PRI value in the ps-l command, they do not display the same value with the same priority.

On the Linux process priority NI and PR what are the differences to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.