A Linux kernel scheduler parameter optimization system and method

Abstract

The present application belongs to the technical field of Linux kernel scheduler, and specifically relates to a Linux kernel scheduler parameter optimization system and method, including a data acquisition module, a large model training and optimization module, a kernel scheduler module, a code generation and verification module, a small model training module, and a small model reasoning module; the large model is responsible for periodically providing a global optimization perspective, generating the initial weights and scheduler prototypes of the small model, extracting rules from long-term accumulated data, and ensuring that the optimization strategy has a global perspective. At the same time, the small model acts as a local adapter to process the dynamic scheduling requirements of the kernel state in real time. This hierarchical optimization mechanism can balance short-term adaptability and long-term performance improvement.

Description

Technical Field

[0001] The present application belongs to the technical field of Linux kernel scheduler, and specifically relates to a Linux kernel scheduler parameter optimization system and method. Background Art

[0002] The Linux kernel scheduler is the core module of operating system resource management, responsible for the reasonable allocation of CPU resources in a multi-tasking environment, thereby balancing system performance and task response time. Traditional Linux schedulers use fixed or empirically configured parameters, such as scheduling delay, time slice granularity, CPU affinity, etc. These parameters are tuned for general scenarios through preset rules, but this static configuration may lead to performance degradation or resource waste in different application scenarios or dynamic loads. Dynamic scheduling strategy optimization lacks a global perspective and can only be optimized under limited rules, which has poor effects on complex multi-tasking scenarios; machine learning-based optimization models rely heavily on historical data and are difficult to adapt to new workload patterns. For complex task dependencies, prediction errors may affect overall performance. In addition, the training process is complex and computationally expensive, making it difficult to apply to small-scale or single-machine environments. Summary of the invention

[0003] Based on the above problems, this application is compatible with a variety of loads and hardware environments, and can dynamically adjust the scheduling strategy according to the characteristics of different tasks. Whether it is CPU-intensive, IO-intensive or mixed loads, the dynamic scheduling mechanism of this project can effectively adapt. Its technical solution is:

[0004] A Linux kernel scheduler parameter optimization system, including a data acquisition module, a large model training and optimization module, a kernel scheduler module, a code generation and verification module, a small model training module, and a small model reasoning module;

[0005] Data collection module: intercepts key information of the system in real time through kernel hooks, and performs preliminary filtering and formatting on the intercepted information; after completing data collection in the kernel, the data is passed to the ring buffer for training of large models and optimization of small models;

[0006] Large model training and optimization module: Use the data from the ring buffer to fine-tune a large model to monitor the global behavior of the system, generate optimized scheduling strategies, and the initial weights and optimization strategies of small models;

[0007] Code generation and verification module: automatically generates complete scheduler code based on the output of the large model training and optimization module, verifies the generated code and sends it to the kernel scheduler module;

[0008] Small model training module: Based on the initial weights and optimization strategies generated by the large model training and optimization module, combined with the runtime data collected from the ring buffer, the small model is incrementally trained and optimized in user mode to generate small model parameters that meet the current system load and scheduling requirements;

[0009] Small model inference module: deploys the small model trained in user state to kernel state, processes the runtime information obtained from kernel hooks in real time, and dynamically generates optimization parameters for the kernel scheduler module;

[0010] Kernel scheduler module: abstracts the existing scheduler logic, extracts common functional components, and redesigns them into an independent and composable modular system.

[0011] Preferably, after the data acquisition module completes data acquisition in the kernel, it transfers the data to the user state through shared memory, system call interface or dedicated debugging file system for use in large model training and small model optimization;

[0012] The data acquisition module supports streaming data output, and the user-mode program can receive data based on event monitoring or timed polling;

[0013] The data acquisition module is scalable and supports dynamic configuration of captured event types and acquisition frequency.

[0014] Preferably, the large model training and optimization module needs to segment or slide the data to organize continuous time periods into fixed-length inputs; a self-supervised learning method is used to learn using the inherent structure or distribution of runtime information.

[0015] Preferably, the setting of the kernel scheduler module includes the following:

[0016] By decomposing the scheduler into multiple core modules, it supports dynamic combination and on-demand loading to adapt to changing system loads and scheduling requirements;

[0017] Through code analysis, function decomposition and runtime monitoring, the dependencies and functional boundaries of each part of the logic are clarified, and each function point is extracted as an independent module. These modules must have clear input and output interfaces and function definitions;

[0018] Allows each component to be implemented and optimized independently, while providing standardized interfaces to support parameter configuration, status query, and runtime updates; supports dynamic loading and unloading functions, that is, replacing certain modules or adjusting their combination order without restarting the kernel according to actual runtime requirements;

[0019] Abstract: A scheduler framework is used as a runtime module management platform to load, initialize, and coordinate the collaborative work of various functional modules; set priority management, parallel execution, and exception recovery; if a module fails or performance degrades, the scheduler framework must be able to automatically fall back to the default implementation to ensure that the basic functions of the scheduler are not interrupted;

[0020] Design a configuration language or description interface through which the large model can directly generate module combination schemes and their parameter configurations; the scheduling strategy output by the large model can be described in a dedicated language, and after the framework is parsed, the corresponding module combination can be directly loaded and the parameters adjusted.

[0021] Preferably, the code generation and verification module includes the following contents:

[0022] After the code is generated, static analysis tools are used to check the syntax correctness of the code, the compliance with kernel development specifications, and potential resource leaks or deadlocks. Dynamic testing is used to verify the actual functionality of the code, including whether the scheduler can correctly handle the task queue, whether priority adjustment is effective, and whether multi-core load balancing is reasonable. These tests are performed in a sandbox or virtual environment to avoid affecting the actual kernel operation.

[0023] The code generation and verification module supports performance evaluation. The generated scheduler code needs to be benchmarked under various load scenarios. If the performance does not meet expectations, the code generation and verification module will generate feedback information for the large model to optimize its design logic.

[0024] The code generation and verification module has a version control function to ensure that the source and change history of each generated code can be traced, and support rollback to the previous version when necessary;

[0025] The verified code will be packaged and sent to the kernel scheduler module, ready to be deployed in the target system;

[0026] The code generation and verification module must also support an automated code deployment process, including loading modules, updating existing scheduler logic, and hot replacement of modules at runtime.

[0027] Preferably, a feedback and closed-loop optimization module is further included: a data feedback path is established between the kernel state and the user state, the operation effect of the scheduler is continuously monitored, and the small model and the large model are optimized using the feedback data to form a dynamic and adaptive closed-loop optimization system;

[0028] Feedback data is used to optimize small models and update large models. Optimizing small models is to adapt small models to new load patterns or system environment changes through incremental training or fine-tuning. Updating large models enables them to extract patterns from global data of larger cycles, providing better strategies for the next round of scheduler module design and small model initialization. After the large model is updated, the newly generated small model weights and scheduler prototypes will be sent to the kernel state through the predefined transmission interface to complete the closed-loop optimization.

[0029] The feedback and closed-loop optimization module includes historical data storage and analysis functions. As feedback data accumulates, the system can identify more complex load patterns and long-term trends.

[0030] Preferably, a version management module is also included to effectively manage the versions of the large model, small model and scheduler module, ensure the reliability and traceability of each update, and provide security for the system;

[0031] The version management module first needs to establish a unique version identifier for all relevant components. Each version includes a specific version number, generation time, model parameter summary, and applicable scenario description. This information is stored in a centralized or distributed version control system to ensure that all components can be retrieved and updated. The version information module not only needs to clarify its source and purpose, but also needs to record the update history of the model and code so that the changes and decision-making basis can be traced back when necessary.

[0032] A version loading and switching mechanism is designed in the version management module: before updating a new small model or scheduler module, the system must first check the compatibility of the current running version with the version to be updated, including interface consistency, whether the input and output formats match, and whether the dependencies are complete; if there is any incompatibility, the version management module must trigger an alarm and refuse to update; at the same time, the version management module must support hot update and rollback functions, load the new version or switch back to the old version without interruption during runtime to ensure system stability.

[0033] A Linux kernel scheduler parameter optimization method comprises the following steps:

[0034] S1. Various information when the kernel intercepts the program running;

[0035] S2. Use the intercepted information to build a large model and a small model; the large model uses a large language model LLM to monitor the global behavior of the system, generate the optimization scheduling strategy and the initial weight and optimization strategy of the small model; the small model uses the reinforcement learning algorithm to dynamically generate optimization parameters for the kernel scheduler module;

[0036] S3. Abstract the used scheduler and abstract the component scheduler module;

[0037] S4. The large model selects appropriate components and their sequence to generate the complete code of the scheduler and then sends it to the kernel state; the large model generates or trains a small model responsible for adjusting the parameters of the generated scheduler and sends it to the kernel state;

[0038] S5. While the small model is continuously being trained, it dynamically and adaptively provides parameters for the scheduler module.

[0039] Preferably, in step S4, a Q-Learning algorithm in reinforcement learning is pre-trained by a large model to adjust the parameters of the scheduler, assuming that the cumulative reward function of the scheduler is maximized in a specific scenario , runtime environment status The real-time operation information provided by the kernel hook defines the action It is the adjustment decision of the scheduler parameters. The Q-Learning model optimizes the parameter adjustment strategy by iteratively updating the Q function. The update formula is:

[0040] ;

[0041] in, is the learning rate, is the discount factor, is the immediate reward of the current action, is the next state after executing the action, For the next state the value of the best possible action in ;

[0042] The large model simulates complex runtime scenarios to evaluate the performance of the scheduler under different configurations and generates High-quality training data is used to guide the Q-Learning model to converge quickly.

[0043] Preferably, in step S5, at the initial stage, the initial value generated by the large model is expressed as:

[0044] ;

[0045] During operation, Q-Learning continues to interact with the scheduler environment, following -greedy strategy selects actions; for the current state , with probability Select the action with the largest Q value in the current Q function, with probability Randomly select exploration actions. After executing the actions, the kernel captures the actual resource utilization of the system as feedback and calculates the immediate reward. Final Strategy Derived by the following formula:

[0046] ;

[0047] This strategy indicates how to adjust parameters in each state to maximize long-term resource utilization efficiency; the goal of Q-Learning is to make Converge to the optimal Q value , which satisfies the Bellman optimal equation:

[0048] ;

[0049] Finally, the Q-Learning model is embedded in the kernel state and can dynamically adapt to changes in the operating environment and continuously optimize the scheduler parameters.

[0050] Compared with the prior art, the present invention has the following beneficial effects:

[0051] 1. Real-time dynamic optimization: Through the kernel-state deployment and real-time reasoning capabilities of the small model, the scheduler can dynamically adjust the strategy based on the data during system runtime. Combined with the context switching, CPU usage and other information captured in real time by the kernel hook, the small model can quickly respond to load changes and achieve efficient resource management.

[0052] 2. Global and local collaborative optimization: The large model is responsible for periodically providing a global optimization perspective, generating the initial weights and scheduler prototypes of the small model, extracting patterns from long-term accumulated data, and ensuring that the optimization strategy has a global perspective. At the same time, the small model acts as a local adapter to handle dynamic scheduling requirements in the kernel state in real time. This hierarchical optimization mechanism can balance short-term adaptability and long-term performance improvement.

[0053] 3. Modular design improves flexibility: The scheduler is abstracted into componentized modules, which support dynamic combination and replacement. The scheduler code generated by the large model according to actual needs can flexibly load or update modules, so as to quickly adapt to different load scenarios and system configurations. This modular design reduces the complexity of scheduler development and enhances the system's scalability.

[0054] 4. Low kernel resource overhead: The training and reasoning of small models are separated. Training is performed in user mode, and reasoning is performed in kernel mode. The small model is designed to be lightweight and can run efficiently within limited kernel resources. Reasoning and parameter updates are performed during CPU idle periods to avoid interference with normal task scheduling.

[0055] 5. Improve performance by transferring knowledge from large models: By migrating the knowledge of large models to small models, the complex global scheduling logic is compressed into lightweight small models, which not only retains the core knowledge of the large model but also significantly reduces the consumption of computing resources. The small model can inherit the intelligence of the large model and execute efficiently in the kernel state.

[0056] 6. Closed-loop feedback mechanism: Through the data feedback from kernel state to user state, combined with the long-term cycle optimization capability of the large model, this project has formed an adaptive closed-loop feedback mechanism. The evaluation results of the scheduler performance and runtime data are continuously transmitted back to the large model, supporting the large model to further optimize the small model and scheduler design, so that the system performance is continuously improved.

[0057] 7. Adapt to complex and changing scenarios: This project is compatible with a variety of loads and hardware environments, and can dynamically adjust scheduling strategies according to the characteristics of different tasks. Whether it is CPU-intensive, IO-intensive or mixed loads, the dynamic scheduling mechanism of this project can effectively adapt.

[0058] 8. Improve development efficiency: By using large models to generate scheduler code and small model parameters, developers can quickly design and verify new scheduling strategies without having to write complex scheduler code from scratch. This generative design significantly improves development efficiency and lowers technical barriers.

[0059] 9. Comprehensive improvement of system performance: Combining the above mechanisms, this project has significantly improved the flexibility and intelligence of the scheduler and achieved comprehensive optimization of system performance, including core indicators such as throughput, task latency and resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 This is the flow chart of this application. DETAILED DESCRIPTION

[0061] The technical solution of the present application is described in detail below through specific embodiments and drawings. It should be understood that the embodiments of the present application and the specific features in the embodiments are detailed descriptions of the technical solution of the present application, rather than limitations on the technical solution of the present application, and the specific technical features may be combined with each other.

[0062] Figure 1 As shown, a Linux kernel scheduler parameter optimization system includes a data acquisition module, a large model training and optimization module, a kernel scheduler module, a code generation and verification module, a small model training module, a small model reasoning module, a feedback and closed-loop optimization module and a version management module.

[0063] Data acquisition module:

[0064] Its core task is to intercept key information of the system runtime in real time through kernel hooks, providing high-quality data support for subsequent modeling and optimization. This module captures runtime information related to task scheduling and resource utilization by deploying a tracing mechanism in the kernel. This information includes but is not limited to context switching frequency, CPU usage, memory allocation, I / O queue length, task priority, and load distribution in a multi-core environment.

[0065] The data collection module performs preliminary filtering and formatting on the intercepted information to reduce the overhead of data transmission and storage. For example, redundant or low-frequency information can be pre-eliminated to retain only the key features related to scheduling. The collected raw data is organized in a structured format to ensure both readability and transmission efficiency. For high-frequency events, the module uses efficient data buffering mechanisms, such as ring buffers, to avoid performance bottlenecks caused by data backlogs.

[0066] The design of the data acquisition module takes into account the data transfer problem between kernel state and user state. After completing data acquisition in the kernel, the data can be transferred to the user state through shared memory, system call interface or dedicated debugging file system for training large models and optimizing small models. In addition, in order to meet real-time requirements, the module supports streaming data output, and user-state programs can receive data based on event monitoring or timed polling.

[0067] The data collection module also has a certain degree of scalability and supports dynamic configuration of the captured event types and collection frequency. For example, more comprehensive information can be captured during the debugging phase, while the focus can be placed on performance-critical features during the deployment phase. At the same time, the module is secure and stable, ensuring that the kernel operation will not be affected even under high load or abnormal conditions. Through this module, a reliable runtime data foundation can be provided for subsequent scheduling optimization.

[0068] Large model training and optimization module:

[0069] Its core task is to train or fine-tune a large model using runtime information collected from kernel hooks to model the global behavior of the system, extract complex load patterns, and generate optimized scheduling strategies. This module handles the entire process from data preprocessing to model training and optimization, and generates the initial weights of small models and prototypes of schedulers in a periodic or on-demand manner.

[0070] After the data enters the module at runtime, it is first cleaned and formatted. The collected raw data may contain missing values ​​or noise, and data quality needs to be ensured by filling or filtering. In addition, the data may involve multiple feature dimensions (such as CPU usage, context switching frequency, priority, etc.), so it needs to be standardized, normalized or reduced in dimension to ensure that it meets the input requirements of the adaptation model. Since kernel data is often time series data, it is also necessary to perform segmentation or sliding window processing to organize continuous time periods into fixed-length inputs.

[0071] During the training process, self-supervised learning methods can avoid dependence on labeled data and use the inherent structure or distribution of runtime information for learning. For example, masking certain features and letting the model predict their values, or enhancing the model's understanding of system behavior through comparative learning methods. Large model training requires efficient use of computing resources and usually runs on multiple GPUs or distributed computing platforms. The training process requires dynamic adjustment of hyperparameters (such as learning rate and weight decay) and combines early stopping strategies to avoid overfitting. After training, the model is performance verified to ensure that the optimization strategy it generates can significantly improve the scheduling performance of the system in a simulated environment.

[0072] The output of the optimized large model includes the initial weights and optimization strategies of the small model, as well as the prototype design of the componentized scheduler. These outputs are passed to related modules for further processing. Module 2 also periodically receives feedback data from the kernel (such as the actual performance of the scheduler), and retrains or fine-tunes the large model based on the new data to ensure that it can adapt to the long-term dynamic changes of the system. Through this module, an intelligent scheduling optimization foundation can be provided for the system from a global perspective.

[0073] Kernel scheduler module:

[0074] Its core task is to abstract the existing scheduler logic, extract common functional components, and redesign them into an independent, composable modular system. This module aims at flexibility and adaptability. By decomposing the scheduler into multiple core modules, such as task selection, priority calculation, load balancing, preemption strategy, etc., it supports dynamic combination and on-demand loading to adapt to the changing system load and scheduling requirements.

[0075] The first step in designing a kernel scheduler module is to analyze existing schedulers (such as Linux's CFS, FIFO, and RR) and their implementation details, and clarify the logical dependencies and functional boundaries of each part through code analysis, functional decomposition, and runtime monitoring. Each function point is extracted as an independent module, and these modules must have clear input and output interfaces and functional definitions. For example, the input of the task selection module is the ready queue and task attributes, and the output is the task to be run next; the input of the load balancing module is multi-core load information, and the output is the migration strategy of tasks between different CPUs.

[0076] The modular design allows each component to be implemented and optimized independently, while providing a standardized interface to ensure seamless integration between modules. This interface is designed as a unified API that supports parameter configuration, status query, and runtime update. In order to enhance the flexibility of the scheduler, the module design also needs to support dynamic loading and unloading functions, that is, to replace certain modules or adjust their combination order without restarting the kernel according to actual runtime requirements.

[0077] The kernel scheduler module also abstracts a scheduler framework as a runtime module management platform, which is responsible for loading, initializing, and coordinating the collaborative work of various functional modules. This framework supports module priority management, parallel execution, and exception recovery. If a module fails or performance degrades, the framework must be able to automatically fall back to the default implementation to ensure that the basic functions of the scheduler are not interrupted.

[0078] In addition, in order to support the dynamic optimization requirements of model generation, the kernel scheduler module also designs a configuration language or description interface, through which the large model can directly generate the module combination scheme and its parameter configuration. This configuration language has high expressiveness and is easy to parse and verify. The scheduling strategy output by the large model can be described in DSL (domain-specific language). After the framework parses it, it directly loads the corresponding module combination and adjusts the parameters.

[0079] Through the kernel scheduler module, the scheduler is transformed from a single, hard-to-adjust overall implementation to a flexible and scalable modular system. This design not only supports the rapid development and testing of new scheduling strategies, but also significantly improves the system's adaptability in diverse load scenarios and provides a solid foundation for subsequent automated optimization and dynamic updates.

[0080] Code generation and verification module:

[0081] Its core task is to automatically generate complete scheduler code based on the output of the large model and strictly verify the generated code to ensure its executability, functionality and security in the kernel environment. This module is a key bridge between the scheduling optimization logic and the actual kernel deployment, and aims to transform the combination and configuration of the scheduler components designed by the large model into a kernel-loadable code implementation.

[0082] The output of the large model is usually the selection of components of the scheduler and their order, plus the interaction rules and parameter configuration between modules. Based on these inputs, module 4 converts these high-level abstract descriptions into low-level concrete codes through a template engine or code generator. Each scheduler component (such as the task selection module and the load balancing module) will have a corresponding code snippet template, which has been optimized and contains the basic logic and interface definition of the component. The code generator will complete the template based on the output of the large model and combine it into a complete kernel scheduler implementation.

[0083] After the code is generated, the code generation and verification module supports multi-level verification of the code to ensure its quality and functionality. On the one hand, static analysis tools are used to check the syntactic correctness of the code, the compliance with kernel development specifications, and potential resource leaks or deadlocks. On the other hand, dynamic testing is used to verify the actual functionality of the code, including whether the scheduler can correctly handle the task queue, whether the priority adjustment is effective, and whether the multi-core load balancing is reasonable. These tests are usually performed in a sandbox or virtual environment to avoid affecting the actual kernel operation.

[0084] The code generation and verification module also supports performance evaluation. The generated scheduler code needs to be benchmarked under various load scenarios to evaluate its performance in terms of throughput, scheduling delay, task fairness, etc. If the performance does not meet expectations, the code generation and verification module will generate feedback information for the large model to optimize its design logic. In addition, the code generation and verification module has a version control function to ensure that the source and change history of each generated code can be traced, and support rollback to the previous version when necessary.

[0085] Finally, the verified code will be packaged and sent to the kernel scheduler module to be deployed in the target system. In order to adapt to the needs of dynamic load changes and rapid iteration, the kernel scheduler module must also support an automated code deployment process, including loading modules, updating existing scheduler logic, and hot replacement of modules at runtime. Through the efficient implementation of the kernel scheduler module, the optimization strategy of the large model can be quickly transformed into practical application, ensuring that the scheduler continues to achieve the optimal state in terms of performance and reliability.

[0086] Small model training module:

[0087] Its core task is to perform incremental training and optimization of the small model in user mode based on the initial weights and optimization strategies generated by the large model, combined with runtime data collected from the kernel, to generate small model parameters that adapt to the current system load and scheduling requirements. The small model is mainly used for kernel-mode reasoning, so the goal of the training module is to ensure that the model is lightweight, efficient, and targeted, while supporting real-time updates and low-latency deployment.

[0088] The training process of the small model is completed in the user state. The initial weights provided by the large model are used as the basis, and the small model can quickly adapt to the new task mode through incremental learning or online learning. The training data is provided by the information intercepted from the kernel by the data acquisition module. In order to improve the training efficiency and model performance, the training data needs to be cleaned, normalized and batched. Unify the multidimensional data into the same numerical range and group them by time series or task type so that the model can capture the dependencies and operation rules between tasks.

[0089] After the small model is trained, its parameters need to be passed to the kernel state for use by the inference module. To achieve this, the training module needs to provide an efficient parameter transmission interface to import the updated model weights into the kernel through system calls or specific kernel interfaces. A version control mechanism needs to be designed during the transmission process to ensure that the kernel state inference module always loads the latest stable version and can quickly roll back to the previous version when an exception occurs.

[0090] The small model also has the ability to update and adapt regularly. The large model can periodically provide new initial weights or optimization strategies, and the small model training module retrains the model based on these updates to ensure its continuous optimization. In addition, when there are significant changes in runtime data (such as changes in load patterns or hardware resources), the training module can actively trigger retraining to quickly adapt to new scenarios. Through this module, the small model can maintain high flexibility and real-time performance, providing accurate parameter support for the kernel-mode scheduler.

[0091] Small model inference module:

[0092] Its core task is to deploy the small model trained in user mode to kernel mode, process the runtime information obtained from kernel hooks in real time in a lightweight way, and dynamically generate optimization parameters for the scheduler. The design of this module takes into account the limited kernel resources and the real-time nature of the scheduling response, ensuring efficient inference while minimizing the impact on kernel performance.

[0093] The deployment of the small model inference module requires an efficient inference engine that specifically optimizes kernel-state inference tasks. Since the kernel lacks support for conventional deep learning frameworks, the small model inference module needs to use a manually implemented matrix operation library or an embedded inference framework, such as an operation implementation based on FP16 optimization. The design of the inference module fully utilizes the existing kernel resources to accelerate calculations while avoiding long-term lock occupancy to ensure minimal interference with other kernel tasks.

[0094] In addition, the small model inference module needs to be fault-tolerant. During runtime, if the input data does not conform to the expected format or an error occurs during the model inference process, the module needs to immediately switch to the default parameters or a predefined safe mode to ensure that the scheduler can continue to operate normally without relying on the output of the small model.

[0095] Finally, the small model inference module also supports performance monitoring and logging. By recording the input, output, and running time of the inference, the performance of the module can be regularly evaluated and the results can be fed back to the user state, providing a basis for subsequent model optimization. Through this module, the small model can achieve efficient inference in the kernel state, provide real-time support for dynamic scheduling optimization, and ensure the stability of kernel operation and low resource usage.

[0096] Feedback and closed-loop optimization module:

[0097] Its core task is to establish a data feedback channel between kernel state and user state, continuously monitor the operation effect of the scheduler, and use these feedback data to optimize small and large models to form a dynamic, adaptive closed-loop optimization system. The key to this module is to achieve efficient collaboration among data collection, performance evaluation, and model optimization, ensuring that the scheduling strategy can respond to short-term changes in real time and continuously improve long-term performance.

[0098] Feedback data mainly comes from the kernel-state scheduler and small model inference module, including key indicators such as task completion time, scheduling delay, CPU and memory usage, and multi-core load balancing status. These data are transmitted back to the user state through a special transmission mechanism for further analysis. In order to improve the availability of feedback data, the module needs to pre-process the data, including denoising, formatting, and statistical feature extraction, to ensure that model training and scheduler optimization can be adjusted based on high-quality information.

[0099] In user mode, feedback data is used for two main purposes: first, to optimize the small model, so that the small model can adapt to new load patterns or system environment changes through incremental training or fine-tuning; second, to update the large model so that it can extract patterns from global data of a larger cycle, and provide better strategies for the next round of scheduler module design and small model initialization. After the large model is updated, the newly generated small model weights and scheduler prototypes will be sent to the kernel mode through the predefined transmission interface to complete the closed-loop optimization.

[0100] In addition, this module needs to be designed with long-term historical data storage and analysis capabilities. As feedback data accumulates, the system can identify more complex load patterns and long-term trends, such as the distribution of task types in different time periods, performance changes of hardware resources, etc. This information can provide more accurate training data for large models and support the long-term optimization strategy of the scheduler, such as pre-configuring scheduling parameters based on historical trends or pre-loading adaptive scheduling modules.

[0101] Through the feedback and closed-loop optimization module, the entire system can form an efficient coordination mechanism between kernel state and user state. The small model and scheduler module respond to system changes in real time in the short term, while the large model provides a global optimization strategy in the long term, thereby achieving dynamic improvement and continuous improvement of scheduling performance to meet the needs of complex and variable load scenarios.

[0102] Version management module:

[0103] Its core task is to effectively manage the versions of large models, small models, and scheduler modules, ensure the reliability and traceability of each update, and provide security for the system. This module runs through the entire life cycle of the model and scheduler, from development, testing to deployment, and always maintains the integrity, consistency, and security of the version.

[0104] The version management module first needs to establish a unique version identifier for all relevant components (such as large models, small models, and scheduler codes). Each version includes a specific version number, generation time, model parameter summary (such as hash value), and applicable scenario description. This information is stored in a centralized or distributed version control system to ensure that all components can be efficiently retrieved and updated. Version information not only needs to clarify its source and purpose, but also needs to record the update history of the model and code so that changes and decision-making basis can be traced back when necessary.

[0105] In the actual deployment process, the version management module has designed a version loading and switching mechanism. Before updating a new small model or scheduler module, the system must first check the compatibility of the current running version with the version to be updated, including interface consistency, whether the input and output formats match, and whether the dependencies are complete. If there is an incompatibility, the module must trigger an alarm and refuse to update. At the same time, the module must support hot update and rollback functions, and load the new version or switch back to the old version without interruption during runtime to ensure system stability.

[0106] Through this module, the entire system can achieve reliable version control and security management while maintaining flexibility, ensuring that large models, small models and scheduler modules always run safely and efficiently in a complex and changing environment.

[0107] A Linux kernel scheduler parameter optimization method comprises the following steps:

[0108] S1. Set a hook in the kernel to intercept various information when the program is running.

[0109] In order to capture information when a program is running (such as process status, context switching, CPU usage, etc.), the present invention designs a hook in the kernel to intercept various types of information generated by the kernel when the program is running for subsequent modeling and optimized scheduling.

[0110] The present invention uses eBPF to set hooks. The scope of collected data includes thread scheduling information (context switching, priority), CPU occupancy, memory usage, IO request queue, and network call. The intercepted information will be transmitted and stored in the kernel buffer (such as ring buffer), and then the kernel state data will be shared to the user state for analysis through the perf interface.

[0111] The present invention designs a kernel module for registering eBPF hooks. In the eBPF program, the data structure to be transmitted is defined, and a ring buffer is created for kernel state and user state to share data. After using clang and llvm to compile the eBPF program into a target file, a user state program is written to load the eBPF program through libbpf and obtain data from the ring buffer. When the compiled user state program is run, it will load the eBPF program, and when a scheduling event occurs, the program will output the intercepted data.

[0112] In addition, this design also optimizes and expands the performance of eEBF.

[0113] (1) Adjust the ring buffer size (max_entries parameter) to optimize performance and memory usage based on event frequency.

[0114] (2) Due to the large amount of data, the ring buffer data is processed through multiple threads in user mode.

[0115] (3) Save the data to a file or database for subsequent analysis.

[0116] (4) Use visualization tools to visualize the collected data in real time.

[0117] After setting up the memory hook, the present invention formats the captured kernel information, deletes useless fields, retains only key information (such as process name, priority, timestamp), and then converts it into a structured format (such as JSON or CSV).

[0118] Finally, check whether the captured data meets expectations through user-mode output logs, and use performance monitoring tools (such as perf stat) to verify whether the hook overhead is within an acceptable range, and optimize for interception failures and performance overhead.

[0119] Through the above steps, the present invention successfully utilizes the ring buffer to realize data sharing between kernel state and user state, and provides an efficient solution for subsequent analysis and optimization.

[0120] S2. Use the intercepted information to model the running program (i.e., fine-tune a large model).

[0121] The present invention first cleans and preprocesses the data collected in the first step, including processing missing values ​​filled with default values; at the same time, it filters out unreasonable outliers, such as abnormal data with negative priority or CPU usage exceeding 100%; normalizes numerical features to the range of [0,1] to facilitate model training; and finally converts them into inputs that LLM can understand through specific templates.

[0122] The cleaned data will be input into the pre-trained large language model to automatically group tasks and identify common load patterns using self-supervised learning. The key to this step is to use the self-supervised learning capabilities of the large model to allow the model to learn the relationship between tasks and the temporal changes in system status through contrastive learning, masking, or sequence reconstruction.

[0123] The goal of fine-tuning is to make the model generate predictions, descriptions, or summaries of system behavior through runtime information. Given a number of data points in a time window, the model can predict the next system behavior or summarize the load pattern. This type of fine-tuning does not require labels, but only requires the construction of reasonable input-output pairs (such as using the previous N steps to predict the N+1 step).

[0124] S3. Abstract the scheduler used by Linux and other platforms, and abstract a component-based scheduler module.

[0125] In order to abstract the scheduler of Linux and other systems and build a component-based scheduler module, the present invention decomposes, abstracts and modularizes the core logic of the scheduler. First, the existing schedulers (such as Linux's CFS, FIFO, RR) and their implementations are analyzed to extract the common logic of the core functions (task selection, priority calculation, load balancing, preemption logic, etc.). These functions are redesigned into modular, reusable components with independent interfaces and clearly defined inputs and outputs.

[0126] The abstraction process includes the following key steps: The first step is to clarify the dependencies and functional boundaries of various parts of the scheduler through static code analysis and dynamic tracing. This can be achieved by analyzing the function call chain of the Linux kernel scheduling code and intercepting the runtime data of the scheduling behavior. The second step is to separate these functions into several logical modules. The task selection module is responsible for determining the next task to run, the priority module determines the execution priority of the task, and the load balancing module handles multi-core load distribution. Each module is designed with a standardized interface to support subsequent dynamic combination and replacement.

[0127] After the modular design is completed, the present invention constructs a scheduler framework that can dynamically load these modules and combine them as needed. The framework supports data transfer and state synchronization between modules, and provides a configuration language or interface to allow the large model in the second step to define the combination order and parameters of the modules as needed. The framework can also support hot loading and updating of modules to adapt to dynamically changing system loads.

[0128] The advantages of the component-based scheduler module are flexibility and scalability, and it can dynamically adjust the scheduling strategy according to different workloads. At the same time, this modular design also provides a basis for the subsequent generation of scheduler code for large models, because the model only needs to output the description and parameters of the module combination, without directly generating complex scheduling logic. Ultimately, this componentized scheduler can serve as an efficient and flexible basic platform to provide optimized scheduling support for cloud computing environments.

[0129] S4. The large model selects appropriate components and their sequence to generate the complete code of the scheduler and then sends it to the kernel state. The large model generates / trains a small model responsible for adjusting the parameters of the generated scheduler and sends it to the kernel state.

[0130] In order to realize the selection of appropriate components and their order by the big model to generate the complete code of the scheduler and send it to the kernel state, the present invention constructs an automated generation and verification process. First, the big model has the ability to understand the scheduling requirements, which comes from the association between runtime behavior and scheduling strategy established through fine-tuning. By inputting the runtime characteristics of a specific scenario (such as system load, task type, hardware resource constraints), the model can generate descriptive output, including component selection and calling order.

[0131] Based on model generation, a code template system is designed, and the core logic of each module has been abstracted into code snippets. These snippets can be dynamically combined through the description generated by the model to generate a complete scheduler code. For example, when the model outputs "task selection: based on priority; load balancing: by CPU occupancy; preemption strategy: non-preemptive", the corresponding template system will automatically combine the code of the task selection module, load balancing module, and preemption logic module, and generate a kernel-compatible scheduler implementation.

[0132] The generated code needs to be checked for syntax and logic by static verification tools to ensure that it complies with kernel development specifications. After compilation, it can be run in a secure and isolated test environment to verify whether the scheduler's behavior is as expected. If the verification passes, the code will be pushed to the target kernel state for execution through the kernel loading mechanism (such as dynamic module loading).

[0133] In order to achieve fast iteration, the generated and verified feedback is sent back to the big model to update its generation logic. If the scheduler does not perform well, the big model can adjust the strategy or parameter settings of the component combination by analyzing the feedback information to generate a better scheduler. Ultimately, this big model-based code generation solution can achieve automation and efficiency in scheduler design and adapt to complex and changing load environments.

[0134] The small model in the present invention adopts Q-learning in the reinforcement learning algorithm. In order to train a Q-Learning algorithm in reinforcement learning (RL) through a large model to adjust the parameters of the scheduler, the present invention redefines the training process and goals at this stage. The core task is to use the simulation scenarios and suggestions generated by the large model to guide the Q-Learning model to learn how to dynamically adjust the parameters of the scheduler (such as task priority weights, load balancing strategies, or preemption thresholds). The role of the large model is mainly reflected in generating a large number of high-quality runtime scenarios and parameter adjustment suggestions, and providing feedback. These data are used for the training of the reinforcement learning model.

[0135] The goal of the Q-Learning algorithm is to maximize the scheduler's cumulative reward function in a specific scenario by interacting with the environment. . Runtime environment status The real-time operation information provided by the kernel hook defines the action It is the adjustment decision of the scheduler parameters. The Q-Learning model optimizes the parameter adjustment strategy by iteratively updating the Q function. The update formula is:

[0136] ;

[0137] in, is the learning rate, is the discount factor, is the immediate reward of the current action, is the next state after executing the action.

[0138] The task of the big model is to provide diverse scenario data and reasonable initial parameter adjustment suggestions. Specifically, the big model simulates complex runtime scenarios, evaluates the performance of the scheduler under different configurations, and generates High-quality training data is used to guide the Q-Learning model to converge quickly. In addition, in order to ensure the real-time adaptability of the model, the Q-Learning algorithm also uses the running information intercepted in real time by the kernel hook for online learning to achieve self-optimization in a dynamic environment.

[0139] It should be noted that the training and reasoning of the small model are separate. The former will be carried out in the user state, and the parameters of the small model training will be penetrated into the kernel state through the system call; the latter will be deployed to the kernel state, so the present invention designs an efficient reasoning engine that can use the CPU idle time for low-overhead calculations. To this end, an optimized lightweight reasoning framework is adopted, and a custom matrix calculation module designed for the kernel environment is used. During the training process, the large model guides the small model to learn the generation logic of the optimal parameters and verify the rationality of its output by generating a large amount of simulation data and parameter adjustment strategies. With the continuous accumulation of runtime data, the large model can regularly provide new training data and parameter adjustment strategies, and iteratively optimize the small model to ensure that it can always adapt to the latest system load requirements.

[0140] The kernel-mode hook intercepts the runtime and sends it to the small model for training. The small model receives timing information in user mode and uses the CPU idle period for training.

[0141] In kernel state, hooks are implemented to intercept runtime information and pass it to the small model in real time for reasoning, building an efficient data transmission and training system, while using the idle period of the CPU for lightweight training. First, real-time data such as task scheduling, context switching, and CPU usage are intercepted through hooks in the kernel. These data are passed to the small model training module in user state through a low-latency sharing mechanism.

[0142] In this scenario, Q-Learning is used to dynamically adjust the parameters of the Linux scheduler. Its input information comes from the real-time runtime data intercepted by the kernel hook. By comparing the resource utilization with the traditional default parameter configuration, Q-Learning aims to improve resource allocation efficiency and system performance. The training process combines the basic framework of reinforcement learning and makes full use of the pre-training results of the large model as the initial value of Q-Learning, thereby improving learning efficiency and accelerating convergence.

[0143] The most essential difference between this and the large model training above is The source of The comparison of resource utilization with the traditional default parameter configuration is used to measure the improvement of the overall system performance. Only provided by the large model. At the beginning, the Q value of Q-Learning Pre-training is performed using simulated scenarios and generated suggestions from a large model. In this stage, large-scale high-quality data is used to make the Q function have reasonable initial estimates for common state-action pairs, reducing the impact of the cold start problem on the learning process. The initial value generated by the large model can be expressed as:

[0144] ;

[0145] in It is a large model for the state and actions Optimization evaluation.

[0146] During operation, Q-Learning continues to interact with the scheduler environment, following -greedy strategy selects actions. For the current state , with probability Select the action with the largest Q value in the current Q function (greedy action) with probability Randomly select exploration actions. After executing the action, the kernel captures the actual resource utilization of the system as feedback and calculates the immediate reward If the new parameter configuration improves resource utilization, a certain reward will be given; if it reduces resource utilization, a certain penalty will be given.

[0147] As the Q function is continuously updated, the model gradually learns the optimal strategy for adjusting the scheduler parameters under different operating conditions. It can be derived by the following formula:

[0148] ;

[0149] This policy indicates how to adjust parameters in each state to maximize long-term resource utilization efficiency. The goal of Q-Learning is to make Converge to the optimal Q value , which satisfies the Bellman optimal equation:

[0150] ;

[0151] The entire process directly links scheduler performance improvement with resource utilization optimization through the design of reward functions, while relying on large model initialization and high-quality scene simulation to reduce training time and improve stability. Finally, the Q-Learning model is embedded in the kernel state, which can dynamically adapt to changes in the operating environment and continuously optimize scheduler parameters, thereby significantly improving the performance of the Linux scheduler.

[0152] In order to ensure the consistency of kernel-mode small model parameters, the parameters trained in user mode can be managed through a version control mechanism to ensure that each update can be fully loaded into kernel mode. To improve system stability, a fault-tolerant mechanism is also designed for the kernel-mode inference module, which falls back to the default scheduling strategy when parameter transmission or loading fails.

[0153] S5. While the small model is continuously being trained, it will dynamically and adaptively provide parameters to the scheduler.

[0154] The small model in kernel state is deployed as a lightweight inference module, which generates scheduler parameters through real-time captured runtime data (such as context switching frequency and CPU load). The inference results are directly applied to the scheduler to guide task allocation and resource management. Since the kernel state model is only responsible for inference, while training is performed in user state, this division of labor significantly reduces the kernel's resource usage while ensuring that the inference results can respond to system changes in real time.

[0155] In order to achieve dynamic adaptation, the kernel-state reasoning module also has the ability to self-adjust. That is, when the characteristics of the runtime data change significantly, the model reasoning module can trigger a parameter update request, report the new data to the user state, and generate a better model through incremental training. The user-state large model also designs a kernel monitoring mechanism to determine whether the current scheduler performance meets expectations. If an abnormality is found, the downgrade strategy is triggered and the default scheduling parameters are used to avoid a significant drop in system performance.

[0156] At the same time, in order to achieve multi-cycle collaborative optimization, the large model regularly generates the initial parameters and training strategies of the small model from a global perspective. This hierarchical update method ensures that the small model can integrate the long-term planning of global optimization on the basis of local real-time adaptation, thereby achieving efficient dynamic management and continuous improvement of the scheduler. At the same time, the large model will provide small models and scheduler prototypes in a larger cycle.

[0157] In order to enable the large model to provide small models and scheduler prototypes in a larger cycle, the present invention establishes a hierarchical optimization mechanism, in which the large model acts as a global optimizer and the small model acts as a local real-time adapter. The role of the large model is to periodically extract patterns from the system's global data, generate new small model structures and initial weights, and update the modular design and optimization logic of the scheduler. The large model analyzes the long-term data accumulation of the system, finds the bottlenecks and room for improvement of the scheduling strategy, and then generates an optimized small model or scheduler prototype. These newly generated models and codes will be passed to the kernel state through the user state interface to replace the old implementation.

[0158] The optimization cycle of the large model is longer than the real-time training of the small model, and it focuses on the long-term behavior patterns of the system. By integrating runtime data over multiple time periods, the large model can generate more efficient scheduler component combinations and more intelligent initial weights for the small model. These optimizations will be sent to the system as global updates in the new cycle. In addition, the large model can also generate multiple different scheduler prototypes based on simulation and emulation, and deploy them to the kernel for AB testing as needed, thereby verifying the effect of the new design in a real environment.

[0159] A feedback closed-loop mechanism is also designed for the entire process: the large model receives statistical data from the kernel state at the end of each cycle, such as task completion time, system throughput, scheduling delay, etc. These data are used to update the optimization logic of the large model to ensure that the next generated model and scheduler are more adaptable to new load patterns and hardware changes. This multi-cycle collaborative optimization mechanism implements dynamic scheduling management from global to local, enabling the system to respond to burst loads in the short term while optimizing overall performance in the long term.

[0160] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A Linux kernel scheduler parameter optimization system, characterized in that: It includes data acquisition module, large model training and optimization module, kernel scheduler module, code generation and verification module, small model training module, and small model reasoning module; Data collection module: intercepts key information of the system in real time during operation through kernel hooks, and performs preliminary filtering and formatting on the intercepted information; After completing data collection in the kernel, the data is passed to the ring buffer for use in training large models and optimizing small models; Large model training and optimization module: Use the data from the ring buffer to fine-tune a large model to monitor the global behavior of the system, generate optimized scheduling strategies, and the initial weights and optimization strategies of small models; Code generation and verification module: automatically generates complete scheduler code based on the output of the large model training and optimization module, verifies the generated code and sends it to the kernel scheduler module; Small model training module: Based on the initial weights and optimization strategies generated by the large model training and optimization module, combined with the runtime data collected from the ring buffer, the small model is incrementally trained and optimized in user mode to generate small model parameters that meet the current system load and scheduling requirements; Small model inference module: deploys the small model trained in user state to kernel state, processes the runtime information obtained from kernel hooks in real time, and dynamically generates optimization parameters for the kernel scheduler module; Kernel scheduler module: abstracts the existing scheduler logic, extracts common functional components, and redesigns them into an independent and composable modular system.

2. The Linux kernel scheduler parameter optimization system according to claim 1, characterized in that: After the data collection module completes data collection in the kernel, it transfers the data to the user state through shared memory, system call interface or dedicated debugging file system for use in large model training and small model optimization; The data acquisition module supports streaming data output, and the user-mode program receives data based on event monitoring or timed polling; The data acquisition module is scalable and supports dynamic configuration of captured event types and acquisition frequency.

3. The Linux kernel scheduler parameter optimization system according to claim 1, characterized in that: In the large model training and optimization module, data needs to be segmented or processed by sliding windows to organize continuous time periods into fixed-length inputs; a self-supervised learning method is used to learn using the intrinsic structure or distribution of runtime information.

4. The Linux kernel scheduler parameter optimization system according to claim 1, characterized in that: The kernel scheduler module settings include the following: By decomposing the scheduler into multiple core modules, it supports dynamic combination and on-demand loading to adapt to changing system loads and scheduling requirements; Through code analysis, function decomposition and runtime monitoring, the dependencies and functional boundaries of each part of the logic are clarified, and each function point is extracted as an independent module. These modules must have clear input and output interfaces and function definitions; Allows each component to be implemented and optimized independently, while providing standardized interfaces to support parameter configuration, status query, and runtime updates; supports dynamic loading and unloading functions, that is, replacing certain modules or adjusting their combination order without restarting the kernel according to actual runtime requirements; Abstract a scheduler framework as a runtime module management platform, responsible for loading, initializing and coordinating the collaborative work of various functional modules; Set up priority management, parallel execution, and exception recovery; if a module fails or performance degrades, the scheduler framework must be able to automatically fall back to the default implementation to ensure that the basic functions of the scheduler are not interrupted; Design a configuration language or description interface through which the large model directly generates module combination schemes and their parameter configurations; the scheduling strategy output by the large model is described in natural language, and after the framework parses it, the corresponding module combination is directly loaded and the parameters are adjusted.

5. The Linux kernel scheduler parameter optimization system according to claim 1, characterized in that: The code generation and verification module includes the following: After the code is generated, static analysis tools are used to check the syntax correctness of the code, the compliance with kernel development specifications, and potential resource leaks or deadlocks. Dynamic testing is used to verify the actual functionality of the code, including whether the scheduler can correctly handle the task queue, whether priority adjustment is effective, and whether multi-core load balancing is reasonable. These tests are performed in a sandbox or virtual environment. The code generation and verification module supports performance evaluation. The generated scheduler code needs to be benchmarked under various load scenarios. If the performance does not meet expectations, the code generation and verification module will generate feedback information for the large model to optimize its design logic. The code generation and verification module has a version control function to ensure that each generated code tracks the source and change history, and supports rolling back to the previous version when necessary; The verified code will be packaged and sent to the kernel scheduler module, ready to be deployed in the target system; The code generation and verification module must also support an automated code deployment process, including loading modules, updating existing scheduler logic, and hot replacement of modules at runtime.

6. The Linux kernel scheduler parameter optimization system according to claim 1, characterized in that: It also includes a feedback and closed-loop optimization module: it establishes a data feedback path between kernel state and user state, continuously monitors the operation effect of the scheduler, and uses these feedback data to optimize small and large models to form a dynamic and adaptive closed-loop optimization system; Feedback data is used to optimize small models and update large models. Optimizing small models is to adapt small models to new load patterns or system environment changes through incremental training or fine-tuning. Updating large models enables them to extract patterns from global data of larger cycles, providing better strategies for the next round of scheduler module design and small model initialization. After the large model is updated, the newly generated small model weights and scheduler prototypes will be sent to the kernel state through the predefined transmission interface to complete the closed-loop optimization. The feedback and closed-loop optimization module includes historical data storage and analysis functions. As feedback data accumulates, the system can identify complex load patterns and long-term trends.

7. The Linux kernel scheduler parameter optimization system according to claim 1, characterized in that: It also includes a version management module to effectively manage the versions of large models, small models, and scheduler modules, ensuring the reliability and traceability of each update and providing security for the system; The version management module first needs to establish a unique version identifier for all relevant components. Each version includes a specific version number, generation time, model parameter summary, and applicable scenario description. This information is stored in a centralized or distributed version control system to ensure that all components can be retrieved and updated. The version information module not only needs to clarify its source and purpose, but also needs to record the update history of the model and code so that the changes and decision-making basis can be traced back when necessary. A version loading and switching mechanism is designed in the version management module: before updating a new small model or scheduler module, the system must first check the compatibility of the current running version with the version to be updated, including interface consistency, whether the input and output formats match, and whether the dependencies are complete; if there is any incompatibility, the version management module must trigger an alarm and refuse to update; at the same time, the version management module must support hot update and rollback functions, load the new version or switch back to the old version without interruption during runtime to ensure system stability.

8. A Linux kernel scheduler parameter optimization method, characterized in that: The following steps are involved: S1. Various information when the kernel intercepts the program running; S2. Use the intercepted information pairs to build a large model and a small model; the large model uses a large language model LLM to monitor the global behavior of the system, generate an optimized scheduling strategy, and the initial weight and optimization strategy of the small model; The small model uses a reinforcement learning algorithm to dynamically generate optimization parameters for the kernel scheduler module; S3. Abstract the used scheduler and abstract the component scheduler module; S4. The large model selects the optimal components and their sequence to generate the complete code of the scheduler and then sends it to the kernel state; the large model generates or trains a small model responsible for adjusting the parameters of the generated scheduler and sends it to the kernel state; S5. While the small model is continuously being trained, it dynamically and adaptively provides parameters for the scheduler module.

9. The Linux kernel scheduler parameter optimization method according to claim 8, characterized in that: In step S4, a Q-Learning algorithm in reinforcement learning is pre-trained by a large model to adjust the parameters of the scheduler, assuming that the cumulative reward function of the scheduler in the set scenario is maximized , runtime environment status The real-time operation information provided by the kernel hook defines the action It is the adjustment decision of the scheduler parameters. The Q-Learning model optimizes the parameter adjustment strategy by iteratively updating the Q function. The update formula is: ； in, is the learning rate, is the discount factor, is the immediate reward of the current action, is the next state after executing the action, For the next state The value of the best action to take in The large model simulates complex runtime scenarios to evaluate the performance of the scheduler under different configurations and generates The training data is used to guide the Q-Learning model to converge quickly.

10. The Linux kernel scheduler parameter optimization method according to claim 8, characterized in that: In step S5, at the initial stage, the initial value generated by the large model is expressed as: ； During operation, Q-Learning continues to interact with the scheduler environment, following -greedy strategy selects actions; for the current state , with probability Select the action with the largest Q value in the current Q function, with probability Randomly select exploration actions. After executing the actions, the kernel captures the actual resource utilization of the system as feedback and calculates the immediate reward. Final Strategy Derived by the following formula: ； This strategy indicates how to adjust parameters in each state to maximize long-term resource utilization efficiency; the goal of Q-Learning is to make Converge to the optimal Q value , which satisfies the Bellman optimal equation: ； Finally, the Q-Learning model is embedded in the kernel state and can dynamically adapt to changes in the operating environment and continuously optimize the scheduler parameters.

Images