Dynamic loading method for Linux kernel scheduling strategy based on AI
By introducing an AI algorithm-based scheduling strategy into the Linux kernel to dynamically load the system, the problems of unpredictable latency and system stability in dynamic loading optimization are solved, improving the real-time performance and stability of the underlying operating system of the mobile robot and enabling adaptive response to different hardware loads.
Patent Information
- Application Number
- CN202510992365.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-18
- Publication Date
- 2025-11-18
AI Technical Summary
In existing technologies, when AI technology is integrated with Linux systems, dynamic loading optimization involves the separation of model inference and resource adjustment, leading to unpredictable latency and system stability issues, making it difficult to meet the high real-time and high reliability requirements of mobile robots.
The system employs an AI-based Linux kernel scheduling strategy to dynamically load components, including a scheduler, a data acquisition module, a data processing module, a dynamic window controller, a preloading execution engine, a monitoring and feedback module, and a prediction model engine. By using an LSTM network to predict the scheduling strategy, it dynamically adjusts resource allocation and preloading, thereby optimizing the underlying performance of the system.
It improves the real-time performance and stability of the underlying operating system of mobile robots, reduces unnecessary resource consumption, enables adaptive response to different hardware loads, and enhances the dynamic loading performance of the system.
Smart Images

Figure CN120973431A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of mobile robot underlying operating system, and particularly relates to a Linux kernel scheduling strategy dynamic loading method based on AI. BACKGROUND
[0002] The Linux operating system is the basis of the operating system in modern industrial control devices and intelligent devices, and many special operating systems are developed based on the Linux operating system, although many improvements, optimizations and secondary developments are made, the kernel architecture is essentially the Linux system.
[0003] With the rapid development of artificial intelligence technology, when the secondary development operating system is carried out based on the Linux system, in order to enhance the underlying performance and intelligence, the AI technology algorithm, model and the like are deeply fused with the underlying kernel architecture of the operating system, so as to improve the underlying basic performance of the operating system.
[0004] With the rise and universal application of mobile robots in the manufacturing field, in order to cope with the high requirements of intelligent manufacturing scenes on mobile robots such as high real-time performance, high reliability and high response speed, the traditional underlying operating system of mobile robots also faces challenges. The advantages and disadvantages of robot movement performance and work performance are restricted by the underlying operating system.
[0005] The Linux operating system is an underlying operating system widely used in the industry, and has extensive and deep application fields and application basis. Robot enterprises carry out secondary development or optimized development based on the operating system to form an underlying operating system suitable for their own robot product technology. Especially with the development of AI technology, how to introduce AI technology into the underlying operating system and optimize its performance is a problem that many industry people have been exploring.
[0006] The fusion of AI technology and Linux system to improve dynamic loading performance and optimize performance is one direction. In the prior art, dynamic loading optimization usually relates to prediction models, preloading strategies, resource management and the like, but there are some common problems, such as separation between model reasoning and resource adjustment, or only a static prediction mechanism. The existence of these drawbacks not only causes problems such as delay unpredictability and system stability when optimizing dynamic loading performance. SUMMARY
[0007] In order to solve the above technical problems, the application proposes an AI-based Linux kernel scheduling strategy dynamic loading system and method, the application develops a Linux kernel-based robot operating system for a mobile robot underlying operating system, and integrates an AI algorithm into the underlying operating system to optimize the dynamic loading process of the system underlying layer, thereby improving the real-time performance of the underlying system. The technical scheme of the application is as follows:
[0008] The first aspect of the application is to propose an AI-based Linux kernel scheduling strategy dynamic loading system, which comprises a scheduler, a data acquisition module, a data processing module, a dynamic window controller, a preloading execution engine, a monitoring and feedback module, and a prediction model engine.
[0009] The scheduler is used for managing hardware resources and task queues.
[0010] The data processing module is used for receiving external real-time index data and performing data cleaning, normalization processing and time series embedding on the real-time index data, and then outputting the data to the data acquisition module.
[0011] The data acquisition module receives the tasks of the scheduler and the data processed by the data processing module, and then writes these data into a ring buffer.
[0012] The prediction model engine receives real-time index data after normalization processing, and based on the current time series window data and historical time series window data, predicts which scheduling strategy in the dynamic window controller is most likely to be needed, and outputs the probability distribution result of the scheduling strategy.
[0013] The dynamic window controller decouples the time length of the prediction window from the fixed tick period of the scheduler by dynamically adjusting the time length, and outputs the time window length.
[0014] The preloading execution engine determines which scheduling strategy corresponding code and information to preload based on the information of the prediction model engine.
[0015] The monitoring and feedback module is used for evaluating the use effect of the scheduling strategy, and transmitting the evaluation result to the prediction model engine and the dynamic window controller for learning and updating.
[0016] Preferably, the dynamic window controller comprises an independent clock source module, an external event triggering module and a window length dynamic calculation module.
[0017] The independent clock source module comprises an independent high-precision clock source
[0018] The external event triggering module is triggered by at least one of the following: external task arrival event, hardware interrupt, and self-defined threshold alarm.
[0019] The window length dynamic calculation module dynamically calculates the prediction window length according to the real-time state of the system; the specific formula is as follows:
[0020] Window_Length = Base + a·DeltaLoad + b·H_Latency
[0021] In the above formula, a and b are adaptive expansion factors; Base is the basic window length; DeltaLoad is the load change rate; H_Latency is the hardware delay value, and b·H_Latency is the hardware delay calibration value; Window_Length is the window length.
[0022] Preferably, the real-time index data includes CPU state, memory and cache, I / O and interrupt, task characteristics and scheduler state.
[0023] Preferably, the Linux kernel scheduling policy includes SCHED_NORMAL scheduling policy, SCHED_FIFO scheduling policy, SCHED_RR scheduling policy, SCHED_BATC scheduling policy and SCHED_IDLE scheduling policy.
[0024] The prediction model engine includes a two-layer LSTM network structure.
[0025] The prediction model engine outputs the probability distribution of the five scheduling policies through the two-layer LSTM architecture and inputs them into the preloading execution engine.
[0026] Preferably, the preloading execution engine includes a hierarchical preloading mechanism.
[0027] The hierarchical preloading mechanism includes the following strategies:
[0028] Level 1: Preload the strategy function pointer table to the L2 cache of the CPU for the strategy higher than the probability pre-trial threshold value d1.
[0029] Level 2: Reserve the allocated memory pool for the strategy higher than the probability pre-trial threshold value d2.
[0030] Level 3: Trigger atomic switching for the strategy higher than the probability pre-trial threshold value d3.
[0031] The atomic switching step is as follows:
[0032] Save the current state;
[0033] Preload new strategy resources;
[0034] Atomically replace the scheduling class pointer;
[0035] Synchronize the state of multiple cores.
[0036] Preferably, the monitoring and feedback module comprises the following mechanisms:
[0037] The indicators within a predetermined time after the activation of the scheduling strategy are evaluated, and if the indicators deteriorate, a rollback or fault-tolerant mechanism is triggered;
[0038] The evaluation indicators are specified;
[0039] By collecting feedback data and feature reorganization, incremental model updating is performed;
[0040] The execution results are fed back to the prediction model engine and the dynamic window controller for learning and updating.
[0041] The second aspect of the present application discloses an AI-based Linux kernel scheduling strategy dynamic loading method, which uses the system disclosed in the first aspect of the present application, and the method comprises the following steps:
[0042] S1, the scheduler issues a task, and the data processing module performs data cleaning, data normalization and time embedding processing on the input real-time indicator data;
[0043] S2, the data acquisition module accepts the task issued by the scheduler and receives data from the data processing module, and then inputs and writes these data into the ring buffer;
[0044] S3, the dynamic window controller decouples the time length of the prediction window and the fixed tick period of the strategy scheduler by dynamically adjusting the time length of the prediction window, and calculates the time window length; the prediction model engine predicts which scheduling strategy in the dynamic window controller is most likely to be needed based on the normalized real-time indicator data and the time series window data, and outputs a probability distribution result;
[0045] S4, the preloading execution engine preloads the corresponding code and data of the scheduling strategy based on the time window length and the probability distribution result of the output scheduling strategy;
[0046] S5, the monitoring and feedback module evaluates the indicators after the activation of the scheduling strategy in real time and determines whether to trigger a rollback or fault-tolerant mechanism;
[0047] The monitoring and feedback module collects feedback data and reorganizes features, and then performs incremental model updating.
[0048] Preferably, the S4 comprises the following steps:
[0049] S4.1, probability distribution input;
[0050] S4.2, strategy decision;
[0051] S4.3, preloading instruction generation;
[0052] S4.4, resource schedule executor.
[0053] The advantages of the present application are as follows:
[0054] The present application aims at a mobile robot underlying operating system, develops a robot operating system based on a Linux kernel, and integrates an AI algorithm into the underlying operating system to optimize a dynamic loading process of a system underlying layer, thereby improving real-time performance of the underlying system.
[0055] The preloading execution engine only preloads strategies most likely to be called, can maximize the benefit of preloading, and reduces unnecessary overhead.
[0056] The present application deeply integrates a lightweight AI model into an operating system kernel / brain system, realizes dynamic preloading of operating system kernel resources, and improves real-time performance of the underlying operating system.
[0057] The present application decouples a time length of a prediction window and a fixed tick period (such as 1 ms) of a strategy scheduler, so that the prediction model engine can adapt to different hardware response speeds and load fluctuations, and avoids prediction deviation or resource waste caused by a fixed time window in a traditional method. BRIEF DESCRIPTION OF DRAWINGS
[0058] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only a part of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.
[0059] Figure 1 It is a whole structure diagram of the embodiment of the present application.
[0060] Figure 2 It is a work flow diagram of the prediction model engine in the embodiment of the present application.
[0061] Figure 3 It is a work flow diagram of the preloading execution engine in the embodiment of the present application. DETAILED DESCRIPTION
[0062] The technical solutions of the present application will be described clearly and completely below in combination with the embodiments of the present application and the drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application.
[0063] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used in the description herein is for describing particular embodiments only and is not intended to be limiting of the application; the use herein of terms such as "comprise" and "comprising", "have" and "having", "include" and "including" and any variations thereof are to be construed as referring to the non-exclusive inclusion of the indicated steps, features or components, such that additional steps, features or components can also be included.
[0064] In the description of the specific embodiments of the application, the technical terms "first", "second" and the like are only used to distinguish different objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number, specific order or primary and secondary relationship of the indicated technical features. In the description of the embodiments of the application, the meaning of "a plurality of" is more than two, unless otherwise explicitly and specifically limited.
[0065] In the present application, the phrase "embodiments" means that the specific features, structures or properties described in conjunction with the embodiments can be included in at least one embodiment of the application. The appearance of this phrase at various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment to other embodiments. It is explicitly and implicitly understood by those skilled in the art that the described embodiments of the application can be combined with other embodiments.
[0066] In the description of the embodiments of the application, the term "and / or" is only a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the three cases of A alone, A and B together, and B alone. In addition, the character " / " in the present application generally represents an "or" relationship between the front and rear associated objects.
[0067] The embodiments of the application will be described in more detail by the following examples. It should be noted that the embodiments of the application are not limited to these examples only.
[0068] In a specific embodiment, as shown in Figure 1 An AI-based Linux kernel scheduling strategy dynamic loading system, the system includes a scheduler, a data acquisition module, a data processing module, a dynamic window controller, a preloading execution engine, a monitoring and feedback module, a prediction model engine;
[0069] In this embodiment, the scheduler is the "brain" of the operating system, which realizes efficient resource utilization and fair task scheduling by managing hardware resources and task queues.
[0070] This embodiment deeply integrates a lightweight AI model into the operating system kernel / brain system, realizes dynamic preloading of operating system kernel resources, and improves the real-time performance of the underlying operating system.
[0071] In this embodiment, the data processing module is configured to receive external real-time indicator data, and perform data cleaning, normalization processing and time series embedding on the real-time indicator data, and output the real-time indicator data to the data collection module.
[0072] In this embodiment, the real-time indicator data is shown in the following table:
[0073] CPU status, including core utilization, run queue length;
[0074] Memory and cache, including memory fragmentation rate, L3 cache miss rate;
[0075] I / O and interrupt, including block device I / O latency, interrupt frequency;
[0076] Task characteristics, including real-time task proportion, task remaining time margin;
[0077] Scheduler status, including context switch frequency, average scheduling delay;
[0078] In this embodiment, the data collection module collects data and outputs to write to the ring buffer.
[0079] In this embodiment, the dynamic window controller decouples the time length of the prediction window and the fixed tick period (e.g. 1ms) of the policy scheduler by dynamically adjusting the time length of the prediction window, so that the prediction model can adapt to different hardware response speeds and load fluctuations, avoiding the prediction bias or resource waste caused by fixed time window in traditional methods.
[0080] In this embodiment, the dynamic window controller includes three sub-modules:
[0081] 1) Independent clock source module, using an independent high-precision clock source (such as TSC, HPET), rather than relying on the tick clock of the scheduler. Its advantage is to avoid the alignment restriction of tick period, supporting sub-microsecond level time precision.
[0082] 2) External event triggering module:
[0083] Through the event triggering mode of external task arrival event, hardware interrupt, custom threshold alarm, etc., rather than using fixed Tick interrupt triggering.
[0084] 3) Window length dynamic calculation module
[0085] The formula is as follows:
[0086] Window_Length = Base + a·DeltaLoad + b·H_Latency
[0087] In the above formula, a and b are adaptive expansion factors; Base is the base window length; DeltaLoad is the load change rate; H_Latency is the hardware delay value, and b H_Latency is the hardware delay calibration value; and Window_Length is the window length.
[0088] In this embodiment, the prediction model engine predicts, according to current and historical data, which scheduling strategy is most likely to be needed in a future period of time (dynamic window) and outputs a probability distribution result.
[0089] The input data thereof is real-time index data after normalization processing, plus time sequence window data, to form a 10-dimensional feature vector data.
[0090] The prediction model engine takes a 2-layer LSTM network as a core model and outputs a probability distribution (after normalization processing) of 5 scheduling strategies.
[0091] In a Linux system, the 5 scheduling strategies are:
[0092] SCHED_NORMAL: the default strategy, which allocates CPU according to the time slice rotation mechanism.
[0093] SCHED_FIFO: a real-time strategy, which has no time slice limit and is preempted by a high-priority task unless.
[0094] SCHED_RR: a real-time strategy, which has a time slice limit and rotates according to the rotation mechanism.
[0095] SCHED_BATCH: a normal strategy, which is optimized for non-interactive batch processing tasks and reduces the scheduling frequency.
[0096] SCHED_IDLE: a normal strategy, which has the lowest priority and can be preempted by other processes.
[0097] The process framework of the prediction model engine is shown in Figure 2 By using a 2-layer LSTM architecture, the system index time sequence features are deeply modeled, and the probability distribution of the scheduling strategy is outputted, thereby providing a precise decision basis for dynamic preloading. The model is compressed to 64 MB through pruning and quantization, supports real-time kernel module embedding, the inference delay is less than or equal to 100 microseconds, and supports microsecond-level strategy adjustment.
[0098] In this embodiment, the preloading execution engine adopts a hierarchical preloading mechanism and is divided into 3 levels (Level):
[0099] Level 1: preloads the strategy function pointer table to the L2 cache of the CPU for a strategy higher than the probability pre-examination threshold value d1 (low-probability strategies are only loaded to L3);
[0100] Level 2 reserves and allocates memory pools for strategies that exceed the probability pre-screening threshold δ2.
[0101] Level 3 will trigger an atomic switch for policies that exceed the probability pre-screening threshold δ3.
[0102] Generally, δ3>δ2>δ1.
[0103] The atomic switching steps are as follows:
[0104] 1) Save the current state (save the old policy context: for example, save the function pointer and scheduling parameters of the current scheduling class to the extended fields of task_struct)
[0105] 2) Preload new strategy resources (preload the code and data of the new strategy according to the probability distribution)
[0106] 3) Atomic replacement of scheduler pointers (using lock-free switching: using compare-and-swap instructions to atomically replace scheduler pointers, ensuring multi-core visibility)
[0107] 4) Synchronize multi-core states (ensure all CPU cores see consistent scheduler pointers through the RCU mechanism)
[0108] This advantage is enhanced real-time performance and improved ability to handle unexpected task scenarios:
[0109] 1) Significantly reduced switchover time;
[0110] 2) The RCU mechanism can ensure multi-core state synchronization and avoid race conditions;
[0111] 3) Probability distribution guides preloading to avoid cache pollution (traditional solutions waste 35% of cache).
[0112] 4) Atomic switching operations are completed in μs, supporting real-time response to burst loads.
[0113] The flowchart of the preload execution engine is as follows: Figure 3 As shown.
[0114] It should be noted that, in this embodiment, the purpose of inputting the probability distribution into the preload execution engine is:
[0115] The preloading execution engine is informed which scheduling strategies are most likely to be used in the coming period, and then the preloading execution engine decides which strategies' code and data to preload based on this information.
[0116] In this embodiment, the preloading execution engine does not directly use the probability distribution, but instead transforms it into specific preloading actions based on decision rules (such as threshold judgment). For example:
[0117] If the probability of a certain strategy exceeds a threshold (e.g., 0.6), then that strategy is preloaded. (A threshold is set for each strategy). If multiple strategies have high probabilities but do not reach a single threshold, then the two strategies with the highest probabilities may be preloaded. In short, it depends on a certain rule set.
[0118] Due to resource constraints, preloading the code and data for all strategies would lead to wasted caching and memory, and could even cause cache pollution. Therefore, it's necessary to select the strategies most likely to be used for preloading. Preloading only the strategies most likely to be invoked maximizes the benefits of preloading and reduces unnecessary overhead.
[0119] In this embodiment, the dynamic window controller and the preloading engine work together as follows:
[0120] Dynamic window time: determines how far the model "looks" (data range), affecting the breadth and reliability of predictions.
[0121] Probability distribution: determines how accurately the model predicts (the basis for decision-making), and affects the accuracy and resource efficiency of preloading.
[0122] Preload execution engine: Combines the two to achieve optimal decisions on "when to load, how much to load, and how to allocate".
[0123] In this embodiment, the dynamic window time and probability distribution influence the preloading execution in a coordinated manner through the following process.
[0124] S1. Dynamic window controller calculates window time.
[0125] S2. The prediction model engine analyzes the historical data within the calculated window period and outputs the strategy probability distribution.
[0126] S3. The preloaded execution engine executes a three-level mechanism based on probability distribution and window time:
[0127] S4. Execution Feedback: Monitor the effectiveness of the strategy and dynamically optimize the window time and model parameters.
[0128] In this embodiment, the monitoring and feedback module is used to evaluate the effectiveness of the strategy and to enable online model learning.
[0129] First, the metrics within 500µs after the strategy is activated are evaluated. If the metrics deteriorate, a rollback or fault tolerance mechanism is triggered. The metrics are used to determine whether the current scheduling strategy is optimal.
[0130] Secondly, the evaluation metrics can be specified, and it is not necessary to use all 10 dimensions. For example, scheduling latency, task timeout rate, and CPU utilization can be used as core metrics for evaluation.
[0131] In addition, by collecting feedback data, features are reorganized, and then incremental model updates are performed.
[0132] Finally, data closed-loop feedback: the execution results are fed back to the prediction model to drive online learning and parameter updates.
[0133] For example, compare current metrics with historical baselines (such as the average of the past hour) to determine system performance fluctuations.
[0134] It should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A Linux kernel scheduling policy dynamic loading system based on AI, characterized in that, It includes a scheduler, a data acquisition module, a data processing module, a dynamic window controller, a preload execution engine, a monitoring and feedback module, and a prediction model engine; The scheduler is used to manage hardware resources and task queues; The data processing module is used to receive external real-time indicator data and perform data cleaning, normalization, and time series embedding on the real-time indicator data before outputting it to the data acquisition module. The data acquisition module receives the task from the scheduler and the data processed by the data processing module, and then writes the data into a circular buffer. The prediction model engine receives real-time indicator data after normalization. Based on the current time series window data and historical time series window data, it predicts which scheduling strategy is most likely to be needed in the dynamic window controller and outputs the probability distribution results of the scheduling strategy. The dynamic window controller decouples the prediction window length from the scheduler's fixed tick period by dynamically adjusting the prediction window length, and outputs the time window length. The preloading execution engine determines which scheduling strategy's code and information to preload based on the information from the prediction model engine. The monitoring and feedback module is used to evaluate the effectiveness of the scheduling strategy and transmit the evaluation results to the prediction model engine and dynamic window controller for them to learn and update.
2. The system according to claim 1, characterized in that, The dynamic window controller includes an independent clock source module, an external event triggering module, and a window length dynamic calculation module. The independent clock source module includes an independent high-precision clock source; The external event triggering module is triggered by at least one of the following methods: external task arrival event, hardware interrupt, and custom threshold alarm. The window length dynamic calculation module dynamically calculates and predicts the window length based on the real-time system status; the specific formula is as follows: Window_Length=Base+α·ΔLoad+β·H_Latency In the above formula, α and β are adaptive expansion factors; Base is the base window length; ΔLoad is the load change rate; H_Latency is the hardware latency value, β·H_Latency is the hardware latency calibration value; and Window_Length is the window length.
3. The system according to claim 1, characterized in that, The real-time metrics data include CPU status, memory and cache, I / O and interrupts, task characteristics, and scheduler status.
4. The system according to claim 1, characterized in that, The Linux kernel scheduling policies include SCHED_NORMAL, SCHED_FIFO, SCHED_RR, SCHED_BATC, and SCHED_IDLE. The prediction model engine includes a 2-layer LSTM network structure; The prediction model engine uses a 2-layer LSTM architecture to output the probability distribution of five scheduling strategies, which are then input into the preload execution engine.
5. The system according to claim 1, characterized in that, The preloaded execution engine includes a hierarchical preload mechanism; The hierarchical preloading mechanism includes the following strategies: Level 1: For policies with probabilities exceeding the pre-approval threshold δ1, preload the policy function pointer table into the CPU's L2 cache; Level 2 reserves and allocates memory pools for strategies that exceed the probability pre-screening threshold δ2. Level 3 will trigger an atomic switch for policies that exceed the probability pre-screening threshold δ3. The atomic switching steps are as follows: Save the current state; Preload new strategy resources; Atomic replacement of the dispatch class pointer; Synchronize multi-core status.
6. The system according to claim 1, characterized in that, The monitoring and feedback module includes the following mechanisms: The indicators are evaluated within a predetermined time after the scheduling strategy is activated. If the indicators deteriorate, a rollback or fault tolerance mechanism is triggered. Specify evaluation indicators; By collecting feedback data and recombining features, incremental model updates are then performed. The execution results are fed back to the prediction model engine and dynamic window controller for them to learn and update.
7. A method for dynamically loading Linux kernel scheduling policies based on AI, employing the system described in any one of claims 1-6, characterized in that, The method includes the following steps: S1, the scheduler issues a task, and the data processing module performs data cleaning, data normalization and time embedding processing on the input real-time indicator data; S2, the data acquisition module accepts the task issued by the scheduler and receives data from the data processing module, and then writes this data into the circular buffer; S3, the dynamic window controller decouples itself from the fixed tick period of the policy scheduler by dynamically adjusting the time length of the prediction window, and calculates the time window length; the prediction model engine predicts which scheduling policy in the dynamic window controller is most likely to be needed based on the normalized real-time indicator data and time series window data, and outputs the probability distribution results. S4, preload the execution engine to preload the corresponding code and data of the scheduling strategy based on the probability distribution results of the time window length and the output scheduling strategy; S5, the monitoring and feedback module evaluates the metrics after the scheduling strategy is activated in real time and determines whether to trigger a rollback or fault tolerance mechanism. The monitoring and feedback module collects feedback data and reconstructs features to perform incremental model updates.
8. The method according to claim 7, characterized in that, S4 includes the following steps: S4.1, Probability distribution input; S4.2, Strategic Decision-Making; S4.3, preload instruction generation; S4.4, Resource Scheduling Executor.