WO2023121104A1

WO2023121104A1 - Interrupt handling method for linux kernel

Info

Publication number: WO2023121104A1
Application number: PCT/KR2022/020178
Authority: WO
Inventors: 이강민
Original assignee: 주식회사 알티스트
Priority date: 2021-12-20
Filing date: 2022-12-13
Publication date: 2023-06-29

Abstract

An interrupt handling method for the Linux kernel may comprise the steps of: receiving a packet and storing same in a memory; determining whether a software interrupt is running on a first CPU from among a plurality of CPUs; searching for the CPU on which the software interrupt is not running from among the plurality of CPUs when the software interrupt is running; and selecting a second CPU from among the plurality of CPUs so as to transmit the packet stored in the memory to the second CPU.

Description

Interrupt Handling in the Linux Kernel

The present invention relates to a method for handling interrupts in the Linux kernel, and more particularly, to a method for ensuring real-time performance of the Linux kernel.

5G and edge computing are enabling new applications such as AR and VR. Low latency and high bandwidth have been proposed as key characteristics of 5G to provide these applications, and telecommunications companies are meeting these requirements through edge computing.

Meanwhile, in the edge computing environment, the Linux kernel is widely used due to its extensive application and driver support. However, since the Linux kernel is not a real-time OS, scheduling delays may occur due to resource contention. This can be an obstacle to achieving sub 1 ms network latency in the Linux network stack. Therefore, there is a need for a Linux kernel processing method capable of maintaining real-time properties.

The present invention is a next-generation edge computing system technology development (R & D) of the Ministry of Science and ICT (Task identification number: 1711125982, Assignment number: 2020-0-00844-002, Research title: Lightweight system for managing and controlling edge server system resources) It was derived from a study conducted as part of software technology development, project management agency: National Institute of Information and Communications Technology Evaluation and Planning, project executing agency: Korea Electronics and Telecommunications Research Institute, research period: 2020.04.01 ~ 2023.12.31).

On the other hand, in all aspects of the present invention, there is no property interest of the Korean government, which is the subject of the project.

An object of the present invention relates to a method for handling interrupts in a Linux kernel in which real-time performance is guaranteed through a process of searching for a CPU.

According to an embodiment of the present invention, a method for processing an interrupt in a Linux kernel that guarantees real-time performance may be provided.

1 is a diagram for explaining a general packet processing situation and a situation in which a delay occurs in the packet processing situation.

2 is a flowchart of an interrupt processing method of a Linux kernel according to an embodiment.

3 is a diagram for explaining an interrupt processing method of a Linux kernel according to an embodiment.

An interrupt processing method of a Linux kernel according to an embodiment includes receiving a packet and storing it in a memory; determining whether a software interrupt is being executed on a first CPU among the plurality of CPUs; searching for a CPU in which the software interrupt is not being executed, among the plurality of CPUs, when the software interrupt is being executed; and selecting a second CPU from among the plurality of CPUs and transmitting the packet stored in the memory to the second CPU.

Here, the step of searching for a CPU in which the software interrupt is not executing may include searching for a CPU whose counter value is 0 among the plurality of CPUs.

Here, the step of searching for a CPU in which the software interrupt is not executing may include sequentially searching for CPUs other than the first CPU among the plurality of CPUs.

Here, the data processing priority of the packet may be higher than the data processing priority of the software interrupt.

Here, the first period, which is the processing period of the software interrupt on the first CPU, may overlap at least a part with the second period, which is the processing period of the packet on the second CPU.

An interrupt processing method of a Linux kernel according to another embodiment includes searching for a CPU in which software interrupts are not being executed among a plurality of CPUs; selecting a first CPU from among the plurality of CPUs; and transmitting a packet to the first CPU, wherein the searching for the CPU may include searching for a CPU whose counter value is 0.

Here, the step of searching for the CPU may include sequentially checking the CPUs included in the plurality of CPUs.

Here, the step of searching for the CPU may include stopping checking of the next CPU when a CPU having a counter value of 0 is identified.

Here, a computer program stored in a computer-readable recording medium may be provided to execute the interrupt handling method of the Linux kernel.

The embodiments described in this specification are intended to clearly explain the spirit of the present invention to those skilled in the art to which the present invention belongs, so the present invention is not limited to the embodiments described in this specification, and the The scope should be construed to include modifications or variations that do not depart from the spirit of the invention.

The terms used in this specification have been selected as general terms that are currently widely used as much as possible in consideration of the functions in the present invention, but these may vary depending on the intention of those skilled in the art, precedents, or the emergence of new technologies to which the present invention belongs. can However, in the case where a specific term is defined and used in an arbitrary meaning, the meaning of the term will be separately described. Therefore, the terms used in this specification should be interpreted based on the actual meaning of the term and the overall content of this specification, not the simple name of the term.

The drawings accompanying this specification are intended to easily explain the present invention, and the shapes shown in the drawings may be exaggerated as necessary to aid understanding of the present invention, so the present invention is not limited by the drawings.

If it is determined that a detailed description of a known configuration or function related to the present invention in this specification may obscure the gist of the present invention, a detailed description thereof will be omitted if necessary.

In the Linux kernel, real-time can mean that results are output within a fixed time for input. For example, if the result of the input is output within 1 ms of the input, this can be interpreted as guaranteeing real-time in the Linux kernel.

Previously, the Linux RT (Real Time) community used the PREEMPT_RT patch with the goal of making the Linux kernel completely preemptible. The PREEMPT_RT patch played a role in reducing the non-preemptible area of the Linux kernel's code path as much as possible. In this case, the non-preemptable region may mean a locked region (critical section) protected by a spin lock.

Conventionally, through the PREEMPT_RT patch, an application with a low priority is prevented from preoccupying a resource to be used by an application with a high priority. Therefore, PREEMPT_RT was able to provide response characteristics close to real-time operating systems.

However, even if PREEMPT_RT is used, a delay situation may occur in which an application having a higher priority is processed later than an application having a lower priority. Specifically, the problem may be caused by the software interrupt mechanism used to protect the implementation driver.

In addition, in order to compensate for the disadvantages of the spin lock, a mutex lock technique that searches for another locked region has been conventionally used. However, since the mutex lock is to find another locked area (critical section), which means a specific area among codes compiled on the same CPU, the bh lock in the softirq mechanism cannot solve the problem that the CPU cannot completely execute the RT task.

The present invention proposes an interrupt handling method of the Linux kernel that guarantees real-time performance to solve these conventional problems.

1(a) is a diagram for explaining a general packet processing situation, and FIG. 1(b) is a diagram for explaining a packet processing delay situation caused by a software interrupt mechanism of the Linux kernel.

Referring to FIG. 1(a), the first CPU processes the RT task and then enters a waiting state waiting for packets. On the timeline of the first CPU of FIG. 1( a ), a portion marked with a red solid line indicates a section in which the RT task is processed, and a section indicated in a dotted line indicates a section in which the RT task is not processed. Specifically, the first CPU processes the RT task until before the reference time point t0, and enters a standby state of waiting for packets from the reference time point t0.

During the standby state of the first CPU, the Linux kernel receives a packet from an external device. At this time, the kernel performs a data processing process on the received packet. For example, a packet data processing process performed by a kernel may be a pre-processing process for a packet processing process of a CPU. On the time line of the first CPU in FIG. 1(a), a portion marked with a solid blue line represents a process in which a kernel processes data for a packet.

When the kernel performs data processing on packets, it stores the processed packets in memory. At this time, the memory may be an internal storage of the Linux kernel. The kernel scheduler may transmit packet-related data to the first CPU to process the packet stored in the memory. That is, the kernel scheduler may cause the first CPU to perform the RT task on the packet. In this case, the time point at which the first CPU receives the packet data may be the second time point t2.

So far, a general packet processing situation without delay in the Linux kernel has been described with reference to FIG. 1(a). In FIG. 1(b), a delay situation for packet processing caused by a software interrupt is described.

Referring to FIG. 1(b), as shown in FIG. 1(a), after performing the RT task, the first CPU enters a waiting state in which a packet is waiting from a reference point in time t0. During the standby condition, a software interrupt may be executed on the first CPU. For example, when a softirq is executed on the first CPU, a softirq bottom half lock (hereinafter referred to as bh lock) may be taken on the first CPU.

While a software interrupt is being performed on the first CPU, the kernel may receive a packet at a first time point t1. The kernel may perform data processing on packets and store the processed packets in memory. On the first CPU timeline of FIG. 1(b), the time when the kernel completes the data processing process for the packet and stores the packet in the memory is indicated as the kernel processing completion time t11.

Packets that have been processed by the kernel and stored in the memory must then be subjected to an RT task process on the CPU, but the first CPU cannot process the packets due to the bh lock caused by the pre-executing software interrupt. That is, a problem arises in that the kernel scheduler cannot transmit a packet to the first CPU immediately after the kernel processing completion point (t11).

The kernel scheduler has to wait until the execution of the software interrupt on the first CPU is completed, which may cause a delay in packet processing. That is, a delay occurs from the kernel processing completion time t11 to the second time point t2 on the first CPU timeline of FIG. 1(b). That is, resource contention occurs with respect to the first CPU, resulting in scheduling delay.

Since the delay impairs real-time performance of the Linux kernel, it may be an obstacle to achieving network latency in the Linux network stack.

In addition, although packets generally have a higher data processing priority than software interrupts, since software interrupts are executed in advance on the CPU, a contradiction occurs in which data processing priority is lower than that of higher priority. .

In order to solve the above problem, the present invention proposes a method of processing packets through a CPU other than the CPU in which software interrupts are executed by modifying the RT scheduler. According to the present invention, the RT task can be performed on the other CPU immediately after the kernel processes the packet through the other CPU, so that the real-time nature of the Linux kernel can be guaranteed.

Hereinafter, an interrupt processing method according to the present invention capable of ensuring real-time performance of the Linux kernel will be described through FIGS. 2 and 3.

Referring to FIG. 2 , the interrupt processing method of the Linux kernel according to an embodiment includes receiving a packet and storing it in a memory (S110), determining whether a software interrupt is running on a CPU (S120), and selecting another CPU. It may include searching (S130), determining whether a software interrupt is running on the CPU (S140), and transmitting a packet stored in the memory to the CPU (S150).

Receiving and storing the packet in the memory (S110) may include receiving a data packet from an external device or another internal component. In this case, the data packet may be a data packet including information or a data packet related to a signal for control. Data packets can vary depending on the device to which the Linux kernel is applied.

The kernel can receive packets and process data on the packets. Data processing of the kernel may be a data pre-processing process for the RT task on the CPU. For example, kernel data processing may be a process of modifying data to meet CPU specifications. Also, for example, kernel data processing may be a process of arranging data so that a calculation process can be efficiently performed on a CPU.

The kernel can process packets as data and store them in memory. At this time, the memory may be an internal device of a device to which the Linux kernel is applied or another external device used as a storage. If the memory is another external device, the kernel can communicate with the external device and transmit the processed data packet.

Examples of the memory include a hard disk drive (HDD), solid state drive (SSD), flash memory, read-only memory (ROM), random access memory (RAM), or cloud storage ( Cloud Storage), etc. However, it is not limited thereto, and the memory may be implemented with various modules for storing data.

The step of determining whether a software interrupt is running on the CPU (S120) may be a previous step for performing an RT task on a packet after the packet processing process of the kernel. Specifically, when a software interrupt is being executed on the CPU, a delay in packet processing occurs, so a step of checking whether the software interrupt is executed in advance is required. In this case, the software interrupt may be a softirq function.

The CPU in step S120 may be the CPU that performed the process of receiving the packet by the kernel. That is, step S120 may be a step in which the kernel checks whether or not the CPU performing the process of receiving the packet was executing a software interrupt before receiving the packet.

Determining whether the software interrupt is being executed may be determined through a value of a software interrupt counter (hereinafter referred to as a counter). Specifically, the kernel scheduler may determine that the software interrupt is not executed when the value of the counter is 0. Also, the kernel scheduler may determine that a software interrupt is being executed when the value of the counter is 1. In this case, the software interrupt counter may be a softirq counter function.

The kernel scheduler may immediately perform step S150 when the counter value of the CPU is 0. That is, when the counter value of the CPU is 0, since the software interrupt is not running, the kernel scheduler can transmit the packet stored in the memory to the CPU. The CPU receiving the packet may process the data of the packet by performing the RT task.

However, the kernel scheduler may perform step S130 when the counter value of the CPU is 1. That is, when the counter value of the CPU is 1, since the software interrupt is running, a process of searching for another CPU that is not running the software interrupt can be performed to avoid a delay.

The step of searching for another CPU (S130) may be a step of sequentially checking a plurality of CPUs included in the device. Sequentially checking may mean checking counter values of CPUs sequentially according to the number of CPUs. That is, the kernel scheduler can individually check the counter values of multiple CPUs, such as #1 CPU, #2 CPU, and #3 CPU.

The step of determining whether a software interrupt is being executed on the CPU (S140) may be similar to step S120. For example, if the CPU in step S120 is CPU No. 1, the kernel scheduler searches for CPU No. 2 through step S130, and in step S140, it can check whether the counter value of CPU No. 2 is 0.

If the counter value of CPU 2 is 1, the kernel scheduler may search for a CPU whose counter value is 0 by repeating steps S130 and S140, such as checking whether the counter value of CPU 3 is 0 again. .

Transmitting the packet stored in the memory to the CPU ( S150 ) may be a step in which the kernel scheduler searches for and/or selects a CPU in which the software interrupt is not running, and transmits the packet stored in the memory to the CPU. At this time, the packet transmitted to the CPU by the kernel scheduler may be a packet processed by the kernel. In addition, the kernel scheduler can send other data for RT tasks to the CPU in addition to packets stored in memory.

A CPU with no software interrupts running can acquire packets by the kernel scheduler and perform RT tasks. In this case, a period in which the CPU in which the software interrupt is not executing performs the RT task for the packet may overlap a period in which the CPU in which the software interrupt is executing performs the software interrupt. That is, while the first CPU performs a software interrupt, the second CPU may obtain the packet by the kernel scheduler and perform the RT task for the packet.

For example, performing the RT task on the received packet by the CPU may be reading the packet and performing a calculation process for processing the packet. Alternatively, the RT task may be a process of modifying a received packet according to a purpose.

Since the software interrupt processing period of the first CPU and the packet processing period of the second CPU overlap, real-time performance of the Linux kernel can be guaranteed. That is, the RT task may be immediately performed on the received packet by utilizing another CPU, which is a resource on which software interrupts are not executed.

Referring to FIG. 3 , the kernel scheduler may perform RT tasks for packets by searching for other CPUs.

After processing the RT task, the first CPU enters a standby state in which it waits for packets from the reference time point t0. During the standby state, a software interrupt other than a packet may be executed on the first CPU at the first sudden point in time s1. While the software interrupt is being performed from the first sudden time point s1, the kernel may receive the packet at the first time point t1.

The kernel receiving the packet may perform a data processing process and store the packet in memory. Since a software interrupt is running on the first CPU, the kernel scheduler can search for another CPU that can immediately handle the RT task for the packet.

The kernel scheduler may sequentially search for a CPU whose counter value is 0 among a plurality of CPUs included in the device. The kernel scheduler may select a second CPU on which software interrupts are not running. The kernel scheduler may transmit packets stored in the memory to the second CPU. Upon receiving the packet, the second CPU may perform an RT task on the packet. In this case, the software interrupt execution period of the first CPU may overlap the RT task processing period for the packet of the second CPU.

The kernel scheduler of the present invention does not wait for the first CPU to complete a software interrupt, but immediately searches for a second CPU capable of processing data and transmits a packet to the second CPU, thereby ensuring real-time performance of the Linux kernel. .

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. Program commands recorded on the medium may be specially designed and configured for the embodiment or may be known and usable to those skilled in computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. - includes hardware devices specially configured to store and execute program instructions, such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of program instructions include high-level language codes that can be executed by a computer using an interpreter, as well as machine language codes such as those produced by a compiler. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

As described above, although the embodiments have been described with limited examples and drawings, those skilled in the art can make various modifications and variations from the above description. For example, the described techniques may be performed in an order different from the method described, and/or components of the described system, structure, device, circuit, etc. may be combined or combined in a different form than the method described, or other components may be used. Or even if it is replaced or substituted by equivalents, appropriate results can be achieved.

Therefore, other implementations, other embodiments, and equivalents of the claims are within the scope of the following claims.

Claims

In the interrupt processing method of the Linux kernel performed by at least one processor,

receiving and storing packets in a memory;

determining whether a software interrupt is being executed on a first CPU among the plurality of CPUs;

searching for a CPU in which the software interrupt is not being executed, among the plurality of CPUs, when the software interrupt is being executed; and

Selecting a second CPU from among the plurality of CPUs and transmitting the packet stored in the memory to the second CPU

How the Linux kernel handles interrupts.
According to claim 1,

The step of searching for a CPU in which the software interrupt is not running includes searching for a CPU whose counter value is 0 among the plurality of CPUs.

How the Linux kernel handles interrupts.
According to claim 1,

The step of searching for a CPU in which the software interrupt is not executing includes sequentially searching for CPUs other than the first CPU among the plurality of CPUs.

How the Linux kernel handles interrupts.
According to claim 1,

The data processing priority of the packet is higher than the data processing priority of the software interrupt.

How the Linux kernel handles interrupts.
According to claim 1,

The first period, which is the processing period of the software interrupt on the first CPU, overlaps at least a part with the second period, which is the processing period of the packet on the second CPU.

How the Linux kernel handles interrupts.
In the interrupt processing method of the Linux kernel performed by at least one processor,

searching for a CPU in which a software interrupt is not running among the plurality of CPUs;

selecting a first CPU from among the plurality of CPUs; and

Transmitting a packet to the first CPU;

The step of searching for the CPU includes searching for a CPU whose counter value is 0.

How the Linux kernel handles interrupts.
According to claim 6,

The step of searching for the CPU includes sequentially checking the CPUs included in the plurality of CPUs.

How the Linux kernel handles interrupts.
According to claim 7,

The step of searching for the CPU includes stopping checking of the next CPU when a CPU whose counter value is 0 is identified.

How the Linux kernel handles interrupts.
A computer-readable non-transitory recording medium on which a program for executing the interrupt handling method of the Linux kernel according to claim 1 is recorded.