A real-time Linux system starvation self-repairing method, device and equipment

Abstract

The present disclosure relates to a real-time Linux system starvation self-repairing method, device and equipment, comprising: an ebpf user state program compiles and loads bytecode of an ebpf kernel state program to a kernel, so that the ebpf kernel state program binds an event of task scheduling switching; the ebpf user state program registers a processing function and associates a buffer defined by the ebpf kernel state program, which is used to receive event information of task scheduling switching captured and recorded by the ebpf kernel state program; the processing function is used to set a repair scheduling strategy to process a task causing a problem event; after the repair scheduling strategy is executed, the original scheduling strategy of the task is restored. The present disclosure can realize automatic detection and repair of the real-time Linux system starvation problem, avoid the use complexity caused by recompiling the kernel, and improve the running stability of the real-time Linux system.

Description

Technical Field

[0001] This disclosure relates to the field of operating system technology, and in particular to a method, apparatus, electronic device, and computer-readable storage medium for real-time Linux system starvation self-healing. Background Technology

[0002] In the Linux operating system, the process scheduler employs various scheduling strategies to manage CPU time allocation. Currently, the main process schedulers in Linux systems include: The stop scheduling class has the highest priority and cannot be preempted. It is typically used in scenarios such as CPU hot-plugging and process migration. Deadline scheduling class, each task needs to be explicitly informed to the kernel of three parameters: period, run time and deadline. The scheduler selects the task with the earliest deadline to run each time until the task is completed, is preempted by a higher priority task or its own deadline changes. Real-time scheduling classes, including SCHED_FIFO and SCHED_RR, use static priorities, with a priority range from 0 to 99, and the highest priority being 99. As long as there is a RT task with a priority of 99, the CPU will be allocated to it first and will not be preempted. The FAIR scheduling class and the CFS (Completely Fair Scheduler) scheduling class typically have scheduling policies such as SCHED_NORMAL, SCHED_BATCH, and SCHED_IDL. They calculate the corresponding virtual runtime (vruntime) based on the priority of the process and select the process with the smallest vruntime to run each time to ensure relative fairness in CPU usage for each process. The Idle scheduling class is the lowest priority scheduling class. It is only executed when there are no other processes running in the system. It is often used for background cleanup and energy saving when the system is idle.

[0003] A process often involves multiple tasks (or threads). The priority level of a process determines the priority of its tasks. When the overall priority of a process is higher than that of other processes, regardless of the execution order of the tasks within that process, other lower-priority processes will be unable to preempt system resources, resulting in a "starvation" problem. In real-time scheduling, SCHED_FIFO is primarily analyzed. Because its core design prioritizes determinism for high-priority tasks, once a real-time task starts running, it will occupy the CPU for a long time. Unless it voluntarily relinquishes the CPU or a higher-priority task preempts it, this real-time task will preempt all processes with lower priorities, potentially preventing other processes from being scheduled, thus causing a "starvation" problem. Figure 1As shown.

[0004] Therefore, there is an urgent need for a real-time Linux system hunger self-healing method that can detect and repair system hunger problems. Summary of the Invention

[0005] To overcome the problems existing in related technologies, this disclosure provides a real-time Linux system starvation self-healing method, apparatus, electronic device, and computer-readable storage medium.

[0006] According to a first aspect of the present disclosure, a method for self-healing starvation in a real-time Linux system is provided, comprising: compiling and loading the bytecode of an ebpf kernel-mode program into the kernel using an ebpf user-mode program, thereby binding the ebpf kernel-mode program to a task scheduling switch event; registering a processing function in the ebpf user-mode program and associating it with a buffer defined by the ebpf kernel-mode program, for receiving task scheduling switch event information captured and recorded by the ebpf kernel-mode program; setting a repair scheduling strategy through the processing function to process the task that caused the problem event; and restoring the original scheduling strategy of the task after executing the repair scheduling strategy.

[0007] In some embodiments, before processing the task that caused the problem event by setting the repair scheduling policy through the processing function, the method further includes: identifying the task status of the process to be scheduled through the ebpf kernel-mode program to obtain the task to be detected; determining the task to be detected, and if it is the task that caused the problem event, sending the information of the problem event to the ebpf user-mode program.

[0008] In some embodiments, the registration of processing functions by the ebpf user-mode program and the association of buffers defined by the ebpf kernel-mode program include: defining an event array mapping and a task array mapping, wherein the event array mapping is used to communicate with the ebpf user-mode program, and the task array mapping is used to record the number of context switches and the time of the tasks.

[0009] In some embodiments, the step of identifying the task state of the process to be scheduled and obtaining the task to be detected through the ebpf kernel-mode program includes: finding the hook point of each task call through the ebpf kernel-mode program and generating a hook function; obtaining the task state value and scheduling policy of the process to be scheduled through the hook function, and determining whether the corresponding task is in a state to be detected based on the state value and scheduling policy; if the task state value of the process to be scheduled is an uninterruptible state and the scheduling policy is a first-in-first-out policy, then the corresponding task is identified as a state to be detected, and the task to be detected is obtained.

[0010] In some embodiments, determining the task that caused the problem event includes: calculating the total number of context switches for the task to be detected to obtain a current count; obtaining the total number of context switches for the previous task through the task array mapping to obtain a previous count; comparing the current count with the previous count to determine whether the task to be detected has performed a context switch within a set time period; if the current count is the same as the previous count, it indicates that the task to be detected has not performed a context switch within the set time period, and the corresponding task to be detected is identified as the task that caused the problem event.

[0011] In some embodiments, the step of setting a repair scheduling policy through the processing function to process the task that caused the problem event includes: setting a repair scheduling policy for the process control descriptor of the process to which the task that caused the problem event belongs through the processing function; and performing process scheduling according to the repair scheduling policy.

[0012] In some embodiments, restoring the original scheduling strategy of the task after executing the repair scheduling strategy includes: setting a timer, and triggering the restoration of the original scheduling strategy of the task periodically based on the timer after executing the repair scheduling strategy.

[0013] According to a second aspect of the present disclosure, a real-time Linux system starvation self-healing device is provided, comprising: a bytecode loading module, used to compile and load the bytecode of an ebpf kernel-mode program into the kernel, thereby binding the ebpf kernel-mode program to a task scheduling switch event; a processing function registration module, used by the ebpf user-mode program to register processing functions associated with a buffer defined by the ebpf kernel-mode program, for receiving task scheduling switch event information captured and recorded by the ebpf kernel-mode program; a problem event handling module, used to set a repair scheduling strategy through the processing function to process the task that causes the problem event; and a scheduling strategy recovery module, used to restore the original scheduling strategy of the task after executing the repair scheduling strategy.

[0014] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement a real-time Linux system starvation self-healing method provided in the first aspect of the present disclosure.

[0015] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, having stored thereon computer program instructions that, when executed by a processor, implement the steps of a real-time Linux system starvation self-healing method provided in the first aspect of the present disclosure.

[0016] The technical solutions provided by the embodiments of this disclosure can include the following beneficial effects: The bytecode of the ebpf kernel-mode program is compiled and loaded into the kernel by the ebpf user-mode program, enabling the ebpf kernel-mode program to bind to task scheduling switching events. The ebpf user-mode program registers a processing function and associates it with a buffer defined by the ebpf kernel-mode program to receive task scheduling switching event information captured and recorded by the ebpf kernel-mode program, thereby achieving the detection of starvation in the Linux system. The processing function sets a repair scheduling policy to handle the tasks causing the problem events, and after executing the repair scheduling policy, restores the original scheduling policy of the tasks, thereby restoring the scheduling state of the relevant tasks after starvation repair. The repair method using the ebpf program avoids the complexity caused by recompiling the kernel, fully utilizes the security sandbox mechanism of ebpf, and improves the operational stability of the real-time Linux system.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0019] Figure 1 This is a schematic diagram illustrating a scenario where a Linux system experiences a starvation problem in existing technologies.

[0020] Figure 2 This is a flowchart illustrating a real-time Linux system starvation self-healing method according to an exemplary embodiment.

[0021] Figure 3 This is a schematic diagram illustrating a scenario of real-time Linux system starvation detection and repair according to an exemplary embodiment.

[0022] Figure 4 This is a flowchart illustrating a problem event identification method according to an exemplary embodiment.

[0023] Figure 5 This is a flowchart illustrating a method for detecting processes to be scheduled, according to an exemplary embodiment.

[0024] Figure 6 This is a flowchart illustrating a method for determining a task that causes a problem event, according to an exemplary embodiment.

[0025] Figure 7 This is a flowchart illustrating a scheduling repair method according to an exemplary embodiment.

[0026] Figure 8This is a block diagram illustrating a real-time Linux system starvation self-healing device according to an exemplary embodiment.

[0027] Figure 9 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0028] The exemplary embodiments will now be described in detail with reference to the accompanying drawings.

[0029] It should be noted that the relevant embodiments and accompanying drawings are only for describing and illustrating exemplary embodiments provided by this disclosure, and not all embodiments of this disclosure, nor should this disclosure be understood to be limited to the relevant exemplary embodiments.

[0030] It should be noted that the terms "first," "second," etc., used in this disclosure are only used to distinguish different steps, devices, or modules. These terms do not represent any specific technical meaning, nor do they indicate any order or interdependence between them.

[0031] It should be noted that the terms “a,” “a plurality of,” and “at least one” used in this disclosure are illustrative rather than restrictive. Unless otherwise expressly indicated in the context, they should be understood as “one or more.”

[0032] It should be noted that the term "and / or" used in this disclosure is used to describe the relationship between related objects, and generally indicates that there are at least three relationships. For example, A and / or B can at least indicate: the existence of A alone, the existence of both A and B, and the existence of B alone.

[0033] It should be noted that the various steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Unless otherwise specified, the scope of this disclosure is not limited by the order in which the steps are described in the relevant embodiments.

[0034] It should be noted that all actions involving the acquisition of signals, information, or data in this disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the location is situated, and with authorization from the owner of the relevant device. Exemplary methods Figure 2 This is a flowchart illustrating a real-time Linux system starvation self-healing method according to an exemplary embodiment, such as... Figure 2 As shown, this real-time Linux system starvation self-healing method is used in Linux operating system process scheduling and includes the following steps: In step S110, the ebpf user-mode program compiles and loads the bytecode of the ebpf kernel-mode program into the kernel, causing the ebpf kernel-mode program to bind to the task scheduling switch event.

[0035] In some embodiments, after the ebpf kernel-mode program detects a starvation problem in the real-time Linux system, it sends the corresponding bytecode to the ebpf user-mode program. The ebpf user-mode program then compiles and loads the bytecode of the ebpf kernel-mode program into the kernel, enabling the ebpf kernel-mode program to bind to task scheduling switching events. This allows ebpf to detect task scheduling switching and identify the starvation problem.

[0036] In step S120, the ebpf user-mode program registers a processing function and associates it with a buffer defined by the ebpf kernel-mode program to receive task scheduling switching event information captured and recorded by the ebpf kernel-mode program.

[0037] In some embodiments, since the ebpf kernel-mode program can capture and record event information of task scheduling switching, it is possible to perform starvation detection on the real-time Linux system through the ebpf kernel-mode program, and record the corresponding problem events after the detection is completed and send them to the ebpf user-mode program. The problem events are event information that causes starvation problems in the real-time Linux system, such as a situation where a high-priority real-time task always preempts the CPU during operation, causing other low-priority processes to be unable to be scheduled.

[0038] In order to receive problem events sent by the ebpf kernel-mode program, the ebpf user-mode program needs to register a handling function handle_event and associate the handling function with a buffer defined by the ebpf kernel-mode program, so that communication can be realized between the ebpf kernel-mode program and the ebpf user-mode program, and the problem events can be transmitted between the two.

[0039] In step S130, a repair scheduling strategy is set through a processing function to process the task that caused the problem event.

[0040] In some embodiments, downgrading the scheduling policy requires a temporary adjustment to the entire process, i.e., changing the priority of all tasks within the process. Otherwise, changing the priority of only a single task will allow other tasks within the process to continue occupying the CPU, preventing other processes from preempting it. Therefore, the EBPF user-space program sets and repairs the scheduling policy through handling functions. For example, it lowers the priority of the process preempting the CPU to a normal level, providing a time window for other processes' tasks to preempt it. This allows for the handling of the task causing the problem, enabling task scheduling to proceed normally. Figure 3 As shown.

[0041] In step S140, after the repair scheduling strategy is executed, the original scheduling strategy of the task is restored.

[0042] In some embodiments, after the starvation problem is resolved by implementing the repair scheduling policy, the scheduling policy of the task that caused the starvation problem is restored to its original scheduling policy, that is, its priority is restored to its original priority, so that the corresponding task can be scheduled according to the original priority, effectively alleviating the starvation problem of the real-time Linux system and ensuring the overall stability of the system operation.

[0043] By using EBPF programs for detection and repair, instead of compiling them into the kernel, the system directly imports the drivers, reducing the complexity caused by recompiling the kernel and fully utilizing the EBPF security sandbox mechanism to improve system stability.

[0044] In the above embodiments, the bytecode of the ebpf kernel-mode program is compiled and loaded into the kernel by the ebpf user-mode program. This allows the ebpf kernel-mode program to bind to task scheduling switching events. The ebpf user-mode program registers a handling function and associates it with a buffer defined by the ebpf kernel-mode program to receive task scheduling switching event information captured and recorded by the ebpf kernel-mode program, thereby enabling the detection of starvation in the Linux system. The handling function sets a repair scheduling policy to handle the task that caused the problem event. After executing the repair scheduling policy, the original scheduling policy of the task is restored, thereby restoring the scheduling state of the relevant task after starvation repair. By using the repair method of the ebpf program, the complexity caused by recompiling the kernel is avoided. The security sandbox mechanism of ebpf is fully utilized, improving the operational stability of the real-time Linux system.

[0045] Figure 4 This is a flowchart illustrating a problem event identification method according to an exemplary embodiment, such as... Figure 4 As shown, the problem event identification method is used before step S130 and includes the following steps: In step S210, the task status of the process to be scheduled is identified by the ebpf kernel-mode program to obtain the task to be detected.

[0046] Specifically, before performing starvation repair, it is necessary to identify the starvation status of the Linux system in real time using the ebpf kernel-mode program. The ebpf kernel-mode program identifies the task status of the process to be scheduled, and determines whether the corresponding task is running, stopped, or in an uninterruptible sleep state. Tasks that may cause problems are then filtered to obtain the tasks to be tested.

[0047] In step S220, the task to be detected is determined. If it is the task that caused the problem event, the problem event information is sent to the ebpf user-space program.

[0048] Specifically, after selecting the tasks to be detected, it is determined whether the task to be detected is the task that caused the problem event. If so, the problem event information is sent to the ebpf user-space program, thereby realizing the identification of the starvation state of the real-time Linux system and sending it to the ebpf user-space program for starvation repair.

[0049] In this embodiment, the ebpf kernel-mode program identifies the task status of the process to be scheduled, filters out tasks that may cause problem events, obtains the task to be detected, and further determines whether the task to be detected is the task that causes the problem event. If so, the problem event information is sent to the ebpf user-mode program to realize the detection of the real-time Linux system starvation state and communication with the ebpf user-mode program, so that system starvation repair can be performed through the ebpf user-mode program.

[0050] In one embodiment, step S120 includes: defining an event array map and a task array map, wherein the event array map is used to communicate with the ebpf user-space program, and the task array map is used to record the number of context switches and the time of the task.

[0051] Specifically, during buffer definition, a BPF_MAP_TYPE_PERF_EVENT_ARRAY array MAP named events is defined by the ebpf user-space program. This event array map is used to communicate with the user-space program and provides fast read and write operations by accessing the event array map through direct indexing. At the same time, a BPF_MAP_TYPE_HASH array MAP named task_map is defined. This task array map stores and retrieves data by calculating hash values ​​using keys, which is suitable for fast lookups and is used to record the number of context switches and times of tasks for subsequent starvation detection and repair.

[0052] The defined event array mapping and task array mapping are inserted into the EBPF kernel-mode program to facilitate interaction between the EBPF user-mode program and the EBPF kernel-mode program, and to record the number of context switches and events of the tasks.

[0053] Figure 5 This is a flowchart illustrating a method for detecting processes to be scheduled, according to an exemplary embodiment, such as... Figure 5 As shown, the method for detecting processes to be scheduled is used in step S210, and includes the following steps: In step S310, the hook point for each task call is found through the ebpf kernel-mode program, and the hook function is generated.

[0054] Specifically, the ebpf kernel-mode program searches for hook points for each task call in the kernel and generates corresponding hook functions lxp_tp__sched__sched_switch. These hook functions then link ebpf with the kernel scheduler's event points, enabling precise recording of each process to facilitate subsequent determination of whether process starvation has occurred.

[0055] In step S320, the status value and scheduling policy of the task to be scheduled are obtained through the hook function, and it is determined whether the corresponding task is in the state to be detected based on the status value and scheduling policy.

[0056] Specifically, the status value and scheduling policy of the task to be scheduled are obtained through hook functions. The status value is represented by the kernel through task_struct, including R (running or runnable state), S (interruptible sleep state), D (uninterruptible sleep state), T (stopped state), X (dead state), etc. The scheduling policy is jointly represented by policy and sched_param (scheduling parameters). Based on the status value and scheduling policy of the task, it is determined whether the corresponding task is in the state to be detected, thus determining whether the corresponding task is a task that may cause starvation.

[0057] In step S330, if the status of the task of the process to be scheduled is uninterruptible and the scheduling policy is first-in-first-out, then the corresponding task is identified as being to be detected, and the task to be detected is obtained.

[0058] Specifically, when a starvation event occurs, the strategy for preempting a process can only be the strategy with higher priority. In real-time Linux systems, the real-time strategy usually adopted is the first-in-first-out strategy, which always has a higher priority than the normal strategy. Therefore, it is possible to determine whether a task is in a state to be detected based on the task scheduling strategy and the task's status value.

[0059] When a task's status is uninterruptible sleep, it means that the task's process needs to continuously perform I / O operations during scheduling and cannot be interrupted or woken up until the I / O operations are completed. Therefore, it may cause starvation problems. If the task's scheduling policy is also a first-in-first-out policy, then the task may cause system starvation during runtime, and it is determined to be in a state to be detected. The corresponding task is a task to be detected.

[0060] In this embodiment, the ebpf kernel-mode program finds the hook point for each task call and generates a hook function. The hook function is used to obtain the task status value and scheduling policy of the process to be scheduled. Based on the status value and scheduling policy, it is determined whether the corresponding task is in a state to be detected. Specifically, when the task status value of the process to be scheduled is an uninterruptible sleep state and the scheduling policy is a first-in-first-out policy, the corresponding task can be determined to be in a state to be detected, and the task to be detected can be obtained. By hooking ebpf with the kernel scheduler, the process status can be accurately recorded, and it can be used to determine whether the task is causing system starvation, thereby realizing the detection of system starvation.

[0061] Figure 6 This is a flowchart illustrating a method for determining a task that causes a problem event, according to an exemplary embodiment, such as... Figure 6 As shown, the method for determining the task that caused the problem event is used in step S220, and includes the following steps: In step S410, the total number of context switches for the task to be detected is calculated to obtain the current count.

[0062] Specifically, after obtaining the task to be tested, in order to further determine whether the task to be tested is preempting the CPU, the total number of context switches of the task to be tested can be counted through the record information of the hook function, and used as the current count.

[0063] In step S420, the total number of context switches for the previous task is obtained through the task array mapping to get the previous count.

[0064] Specifically, in order to determine whether the task under test is causing system starvation, the total number of context switches of the last scheduled task is extracted through task array mapping and used as the previous count, so as to compare with the current count and determine whether a system starvation problem has occurred.

[0065] In step S430, the relationship between the current count and the previous count is compared to determine whether the task to be detected has performed a context switch within the set time period.

[0066] Specifically, if the task process is constantly being scheduled, the current count and the previous count will differ over a period of time. Therefore, by comparing the relationship between the current count and the previous count, it can be determined whether the task under test has performed a context switch within a set time period, so as to detect whether the process is switching normally.

[0067] In step S440, if the current count is the same as the previous count, it means that the task to be detected has not performed a context switch within the set time period, and the corresponding task to be detected is identified as the task that caused the problem event.

[0068] Specifically, when the current count is the same as the previous count, it indicates that the task under test has not performed a context switch within the set time period, resulting in a system starvation problem. The corresponding task under test is identified as the task that caused the problem event and can be marked as a problem for subsequent processing.

[0069] The set duration can be configured according to the actual situation, such as 5 seconds. If the task to be detected does not perform a context switch within 5 seconds, it indicates that the real-time Linux system is experiencing a starvation problem. The problem event is sent to the ebpf user-space program through bpf_perf_event_output.

[0070] In this embodiment, the current count is obtained by calculating the total number of context switches of the task to be detected. At the same time, the previous count is obtained by obtaining the total number of context switches of the previous task based on the task array mapping. The relationship between the current count and the previous count is compared, and it is determined whether the task to be detected has performed a context switch within a set time period. When the current count and the previous count are the same, it means that the task to be detected has not performed a context switch within the set time period. Then, the corresponding task to be detected is determined to be the task that caused the problem event, thereby realizing the judgment of the real-time task that causes system starvation, completing the starvation problem detection, and facilitating subsequent starvation repair.

[0071] Figure 7 This is a flowchart illustrating a scheduling repair method according to an exemplary embodiment, such as... Figure 7 As shown, the scheduling repair method is used in step S130 and includes the following steps: In step S510, a repair scheduling policy is set for the process control character of the task that caused the problem event through a processing function.

[0072] Specifically, the ebpf user-space program processes the received problem events through the handling_event function. Based on the task that caused the problem event, it obtains the process control character to which it belongs. Through the process control character, it sets a repair scheduling strategy to fix system starvation. For example, it lowers the priority of the task corresponding to the problem event to a normal level, provides a time window for other tasks to preempt, realizes normal task scheduling, effectively alleviates the starvation problem caused by real-time tasks, and improves the overall robustness of the system.

[0073] In step S520, the process is scheduled according to the repair scheduling policy.

[0074] Specifically, after obtaining the set repair scheduling policy, the process is scheduled based on the repair scheduling policy, thereby repairing the starvation of the real-time Linux system, alleviating the starvation phenomenon caused by real-time tasks preempting the CPU, and greatly improving the overall robustness of the system.

[0075] In this embodiment, a repair scheduling policy is set for the process control character of the task that caused the problem event through the processing function. The process is scheduled according to the repair scheduling policy, which can effectively alleviate the system starvation caused by real-time tasks preempting the CPU and greatly improve the overall robustness of the system.

[0076] In one embodiment, step S140 includes: setting a timer to trigger the original scheduling strategy of the recovery task periodically after the repair scheduling strategy is executed.

[0077] Specifically, after executing the repair scheduling strategy, in order to restore the original scheduling strategy, a timer can be preset, for example, a 5-second timer. Five seconds after executing the repair scheduling strategy, the original scheduling strategy of the restored task is triggered periodically, and the task is scheduled according to its original priority. That is, the scheduling strategy of all processes to be scheduled is restored to ensure the normal scheduling of all tasks. Exemplary device Figure 8 This is a block diagram illustrating a real-time Linux system starvation self-healing device according to an exemplary embodiment. (Refer to...) Figure 8 The device 800 includes a bytecode loading module 810, a processing function registration module 820, a problem event handling module 830, and a scheduling policy recovery module 840.

[0078] The bytecode loading module 810 is used to compile ebpf user-mode programs and load ebpf kernel-mode program bytecode into the kernel, so that the ebpf kernel-mode program is bound to the task scheduling switch event; The processing function registration module 820 is used to register processing functions associated with buffers defined by ebpf kernel-mode programs for ebpf user-mode programs, and is used to receive task scheduling switching event information captured and recorded by ebpf kernel-mode programs; The problem event handling module 830 is used to handle the task that caused the problem event by setting a repair scheduling strategy through the processing function; The scheduling strategy recovery module 840 is used to restore the original scheduling strategy of a task after the scheduling strategy is repaired.

[0079] In some embodiments, the device further includes: a task state identification module, used to identify the task state of the process to be scheduled through the ebpf kernel-mode program to obtain the task to be detected; and a task to be detected judgment module, used to judge the task to be detected, and if it is the task that caused the problem event, to send the problem event information to the ebpf user-mode program.

[0080] In some embodiments, the apparatus further includes: an array definition module for defining an event array map and a task array map, wherein the event array map is used to communicate with the ebpf user-space program, and the task array map is used to record the number of context switches and the time of the task.

[0081] In some embodiments, the apparatus further includes: a hook function generation module, used to find the hook point of each task call through the ebpf kernel-mode program and generate a hook function; a task status judgment module, used to obtain the status value and scheduling policy of the task of the process to be scheduled through the hook function, and to determine whether the corresponding task is in a state to be detected based on the status value and scheduling policy; and a task to be detected acquisition module, used to identify the corresponding task as a state to be detected if the status value of the task of the process to be scheduled is uninterruptible and the scheduling policy is a first-in-first-out policy, and to obtain the task to be detected.

[0082] In some embodiments, the device further includes: a current count acquisition module, configured to calculate the total number of context switches of the task to be detected to obtain the current count; a previous count module, configured to obtain the total number of context switches of the previous task through task array mapping to obtain the previous count; a count comparison module, configured to compare the current count and the previous count to determine whether the task to be detected has performed a context switch within a set time period; and a problem task determination module, configured to determine that if the current count is the same as the previous count, it means that the task to be detected has not performed a context switch within the set time period, and thus identify the corresponding task to be detected as the task that caused the problem event.

[0083] In some embodiments, the apparatus further includes: a repair strategy setting module, configured to set a repair scheduling strategy for the process control character to which the task causing the problem event belongs through a processing function; and a scheduling execution module, configured to perform scheduling on the process according to the repair scheduling strategy.

[0084] In some embodiments, the device further includes a timer setting module for presetting a timer and, after executing the repair scheduling strategy, triggering the original scheduling strategy of the recovery task periodically based on the timer.

[0085] In the above embodiments, the operation of this device realizes a real-time Linux system starvation self-healing method, ensuring that the device can implement all the contents of a real-time Linux system starvation self-healing method. Exemplary electronic devices Figure 9 This is a block diagram illustrating an electronic device 900 according to an exemplary embodiment. The electronic device 900 may be a vehicle controller, an in-vehicle terminal, an in-vehicle computer, or other types of electronic devices.

[0086] Reference Figure 9 The electronic device 900 may include at least one processor 910 and a memory 920. The processor 910 can execute instructions stored in the memory 920. The processor 910 is communicatively connected to the memory 920 via a data bus. In addition to the memory 920, the processor 910 can also be communicatively connected to an input device 930, an output device 940, and a communication device 950 via the data bus.

[0087] Processor 910 can be any conventional processor, such as a commercially available CPU. Processors may also include graphics processing units (GPUs), field-programmable gate arrays (FPGAs), systems on chips (SOCs), application-specific integrated circuits (ASICs), or combinations thereof.

[0088] The memory 920 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0089] In this embodiment of the present disclosure, the memory 920 stores executable instructions, and the processor 910 can read the executable instructions from the memory 920 and execute the instructions to implement all or part of the steps of the real-time Linux system starvation self-healing method described in any of the exemplary embodiments above. Exemplary computer-readable storage media In addition to the methods and apparatus described above, exemplary embodiments of this disclosure may also be a computer program product or a computer-readable storage medium storing the computer program product. The computer product includes computer program instructions that can be executed by a processor to perform all or part of the steps described in any of the methods in the exemplary embodiments described above.

[0090] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages, and scripting languages ​​(e.g., Python). The program code can be executed entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0091] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: static random access memory (SRAM) having one or more electrically connected wires; electrically erasable programmable read-only memory (EEPROM); erasable programmable read-only memory (EPROM); programmable read-only memory (PROM); read-only memory (ROM); magnetic storage; flash memory; magnetic disk or optical disk; or any suitable combination thereof. Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of this disclosure. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0092] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A real-time Linux system starvation self-healing method, characterized in that, Includes the following steps: The ebpf user-mode program compiles and loads the bytecode of the ebpf kernel-mode program into the kernel, binding the ebpf kernel-mode program to a task scheduling switch event; The ebpf user-mode program registers a processing function and associates it with a buffer defined by the ebpf kernel-mode program to receive task scheduling switching event information captured and recorded by the ebpf kernel-mode program; The processing function sets a repair scheduling strategy to handle the task that caused the problem event; After executing the repair scheduling strategy, the original scheduling strategy of the task is restored.

2. The real-time Linux system starvation self-healing method according to claim 1, characterized in that, Before the step of setting the repair scheduling strategy through the processing function to process the task that caused the problem event, the method further includes: The task to be detected is obtained by identifying the task status of the process to be scheduled through the ebpf kernel-mode program; If the task to be detected is the one that caused the problem event, then the information of the problem event is sent to the ebpf user-space program.

3. The real-time Linux system starvation self-healing method according to claim 2, characterized in that, The ebpf user-mode program registers a processing function and associates it with a buffer defined by the ebpf kernel-mode program, including: Define an event array map and a task array map. The event array map is used to communicate with the ebpf user-space program, and the task array map is used to record the number of context switches and the time of the task.

4. A real-time Linux system starvation self-healing method according to claim 3, characterized in that, The process of identifying the task status of the process to be scheduled through the ebpf kernel-mode program to obtain the task to be detected includes: The ebpf kernel-mode program finds the hook points for each task call and generates hook functions; The hook function obtains the status value and scheduling policy of the task to be scheduled, and determines whether the corresponding task is in a state to be detected based on the status value and scheduling policy. If the status of the task to be scheduled is uninterruptible and the scheduling policy is first-in-first-out, then the corresponding task is identified as being to be detected, and the task to be detected is obtained.

5. A real-time Linux system starvation self-healing method according to any one of claims 3 or 4, characterized in that, The tasks that determine the cause of the problem event include: Calculate the total number of context switches for the task to be detected to obtain the current count; The total number of context switches for the previous task is obtained through the task array mapping, thus obtaining the previous count; By comparing the current count with the previous count, it is determined whether the task to be detected has performed a context switch within a set time period; If the current count is the same as the previous count, it means that the task to be detected has not performed a context switch within the set time period, and the corresponding task to be detected is identified as the task that caused the problem event.

6. A real-time Linux system starvation self-healing method according to claim 1, characterized in that, The step of setting a repair scheduling strategy through the processing function to process the task that caused the problem event includes: The processing function sets a repair scheduling strategy for the process control descriptor of the process to which the task causing the problem event belongs. The process is scheduled according to the repair scheduling strategy.

7. A real-time Linux system starvation self-healing method according to claim 1, characterized in that, After executing the repair scheduling strategy, restoring the original scheduling strategy of the task includes: A preset timer is used to periodically trigger the restoration of the original scheduling strategy for the task after the repair scheduling strategy is executed.

8. A real-time Linux system starvation self-healing device, characterized in that, include: The bytecode loading module is used to compile ebpf user-mode programs and load ebpf kernel-mode program bytecode into the kernel, so that the ebpf kernel-mode program is bound to the task scheduling switch event; The processing function registration module is used for EBPF user-mode programs to register processing functions associated with buffers defined by the EBPF kernel-mode programs, and is used to receive task scheduling switching event information captured and recorded by the EBPF kernel-mode programs; The problem event handling module is used to set a repair scheduling strategy through the processing function to handle the task that caused the problem event; The scheduling strategy recovery module is used to restore the original scheduling strategy of the task after the repair scheduling strategy is executed.

9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement a real-time Linux system starvation self-healing method as described in any one of claims 1-7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the steps of a real-time Linux system starvation self-healing method as described in any one of claims 1-7.

Images