Shulou(Shulou.com)06/01 Report--

This article is about how to parse the messy real-time thread priority of the Linux kernel. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article.

Background

Linux divides processes into ordinary processes and real-time processes. Ordinary processes use scheduling algorithms such as CFS, while real-time processes use SCHED_FIFO or SCHED_RR.

Regardless of priority, real-time processes take precedence over all processes in SCHED_NORMAL, because the latter are ordinary non-real-time processes.

Priority of kernel threads

The Linux kernel places a large (and growing) amount of work in kernel threads, which are special processes running in the kernel address space. Most kernel threads run in the SCHED_NORMAL class and must compete with ordinary user-space processes for CPU time. But there are some kernel threads whose developers think they are very special and should have a higher priority than user-space processes. So these kernel threads are also put into SCHED_FIFO.

So the question is, how much should the real-time priority of a kernel thread be set?

To answer this question, you not only need to determine whether this thread is more important than all other real-time threads, but also compare who is more important to the real-time process in user mode. This is a difficult question to answer, not to mention the fact that the answer is likely to vary from system to system and mode of operation.

So generally speaking, kernel developers just choose a real-time priority according to their mood.

Some of the current kernel real-time threads are as follows:

Recently, Peter Zijlstra, the great god, saw that kernel developers casually set priorities to kernel threads, and finally couldn't watch it any longer, criticizing this practice of putting kernel threads into SCHED_FIFO:

"the kernel has no clue what actual priority it should use for various things, so it is useless (or worse, counter productive) to even try"

So he posted a series of [PATCH 00DB 23] sched: Remove FIFO priorities from modules simply deleted all the interfaces that set the priority of kernel threads, so that no one else was messing around.

This series of Patch (click to read the original) mainly does the following things:

The original sched_setschedule () / sched_setattr () interface has been deleted

Increased

Sched_set_fifo (p)

Sched_set_fifo_low (p)

Sched_set_normal (p, nice)

A call to sched_set_fifo () places the specified process in the SCHED_FIFO class with a priority of 50 min-only half the position between min and max.

For threads with less urgent needs, sched_set_fifo_low () sets the priority to the lowest value (1).

Calling sched_set_normal () returns the thread to the SCHED_NORMAL class with a given good value.

By leaving only these three interfaces, you can prevent developers from constantly selecting kernel thread priorities at random, because this would be pointless, but system administrators can still adjust the priorities of different input / threads as needed.

So far, many of this series of Patch have received Reviewed-by, and it is believed that if integrated, the messy priority of kernel threads will continue to improve.

This is how to parse the messy real-time thread priority of the Linux kernel. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.