A QoS-driven virtual CPU scheduling system and method for satellite ground station
By building a QoS-driven virtual CPU scheduling system in the virtualized environment of the satellite ground station, the problem of insufficient resource guarantee during the satellite transit window was solved, and efficient scheduling and service quality assurance for critical tasks were achieved, meeting the business needs in the satellite-ground interaction scenario.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING UNIV OF POSTS & TELECOMM
- Filing Date
- 2026-03-20
- Publication Date
- 2026-06-16
AI Technical Summary
In the virtualized environment of satellite ground stations, the existing scheduling mechanism lacks consensus on business semantics, resulting in insufficient resource guarantee for critical tasks during satellite transit windows, leading to deadline defaults and response delay fluctuations, making it difficult to meet the service quality requirements in satellite-ground interaction scenarios.
A QoS-driven virtual CPU scheduling system for satellite ground stations is adopted. The service quality monitoring module monitors the task pressure information within the virtual machine, the resource quota determination module allocates CPU resources according to the pressure index weight, and the scheduling module executes scheduling according to the quota. This constructs a resource guarantee mechanism driven by task demand, ensuring computing power guarantee for critical tasks during the satellite transit window.
It effectively reduced the risk of defaulting on deadlines for critical missions during satellite transit windows, improved mission completion rates and service quality, alleviated the mismatch problem of two-level scheduling, and achieved differentiated resource guarantees for critical missions.
Smart Images
Figure CN122220102A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of computer virtualization technology, specifically relating to a QoS-driven virtual CPU scheduling system and method for satellite ground stations. Background Technology
[0002] With the deep integration of commercial aerospace and cloud computing technologies, satellite ground stations are gradually providing capabilities in a service-oriented manner, forming the "Ground Station as a Service" (GaaS) model represented by AWS Ground Station and Azure Orbital. The GaaS model combines antenna resources, link access, and virtualized computing platforms, enabling users to obtain communication and data services on demand during satellite transit. Under the GaaS architecture, different users or services run on the same physical infrastructure in the form of virtual machines or containers, with CPU resources uniformly scheduled by the host operating system. However, unlike traditional IaaS scenarios, satellite ground station tasks have strong time window constraints: the satellite transit window is finite and non-extendable, and tasks must complete critical operations such as signal reception and data processing within the window period; once the window ends, the task loses its business value.
[0003] Virtualization environments typically employ a two-tier scheduling mechanism. The host operating system performs unified scheduling of virtual CPUs (vCPUs) with the goals of fairness and load balancing, while the operating system inside the virtual machine performs secondary scheduling of threads based on its own task characteristics. There is a lack of consensus on business semantics between the two schedulers, and scheduling decisions are independent and may even conflict. This scheduling mismatch is particularly pronounced during satellite transit windows: even if critical tasks are prioritized within the virtual machine, the host layer may still interrupt or delay vCPU execution due to resource contention from other instances, leading to deadline breaches, response latency fluctuations, and other issues that severely impact service QoS. Therefore, these technologies struggle to meet the resource guarantee requirements of critical tasks during satellite transit windows in satellite-to-ground interaction scenarios. Summary of the Invention
[0004] The purpose of this invention is to provide a QoS-driven virtual CPU scheduling system and method for satellite ground stations, which can solve the problems existing in the background art.
[0005] To solve the above-mentioned technical problems, the present invention is implemented as follows: In a first aspect, embodiments of the present invention provide a QoS-driven virtual CPU scheduling system for satellite ground stations, including a host machine and multiple virtual machines running on the host machine; The virtual machine includes: The service quality monitoring module is used to monitor the stress information of each task within this virtual machine and aggregate the stress information of multiple tasks within this virtual machine into a stress index for this virtual machine; wherein, the stress index is used to characterize the CPU resource requirements of the corresponding virtual machine; The host machine includes: The resource quota determination module is used to allocate CPU resources available for the next control cycle to each virtual machine based on the weight of each virtual machine's stress index at the end of each control cycle. The scheduling module is used to schedule the virtual CPUs of each virtual machine to run on the physical CPUs within each control cycle, based on the CPU resources allocated to each virtual machine within that control cycle.
[0006] Optionally, the service quality monitoring module is further configured to monitor the transit status information of the virtual machine; the transit status information is used to indicate whether the corresponding virtual machine is in the transit period of a satellite. The resource quota determination module is specifically used for: At the end of each control cycle, based on the transit status information of each virtual machine, the critical virtual machines currently in the satellite transit period are identified, and a minimum guarantee quota is allocated to each critical virtual machine. The remaining CPU resources to be allocated are determined based on the difference between the total available CPU resources and all allocated minimum guaranteed quotas. Based on the stress index of each virtual machine, the remaining CPU resources to be allocated are distributed proportionally to each virtual machine to determine the CPU resources allocated to each virtual machine in the next control cycle; among them, the virtual machine with higher service quality pressure will receive more remaining CPU resources to be allocated.
[0007] Optionally, the service quality monitoring module is used for: Obtain the number of time-overdue violations for each real-time task within this virtual machine, and determine the pressure information for each real-time task based on the number of time-overdue violations; Obtain the run queue length or waiting time of each general task within this virtual machine, and determine the pressure information of each general task based on the run queue length or the waiting time; The stress information of all real-time tasks and all general tasks on this virtual machine are aggregated to obtain the stress index of this virtual machine.
[0008] Optionally, the scheduling module is used to: Monitor the remaining CPU resources of each virtual machine in each control cycle; When scheduling any virtual CPU of any virtual machine to run on a physical CPU, the maximum runtime of this scheduling is determined based on the remaining CPU resources of the virtual machine in the current control period; the less remaining CPU resources the virtual machine has in the current control period, the shorter the maximum runtime allocated to its virtual CPU. When the virtual CPU starts running, record the start timestamp of this run; when the virtual CPU stops running, record the end timestamp of this run. The actual duration of this run is calculated based on the start timestamp and the end timestamp, and the quota value corresponding to the actual duration of this run is deducted from the remaining CPU resources of the virtual machine in the current control cycle.
[0009] Optionally, each virtual machine is configured with a high-priority scheduling queue and a low-priority scheduling queue; the scheduling module is further configured to: Monitor the remaining CPU resources of each virtual machine in each control cycle; If any virtual machine task is in a ready state, check if there is any idle physical CPU. If no physical CPUs are available, check the remaining CPU resources of the virtual machine; If the virtual machine has more than zero remaining CPU resources, add the virtual CPU of the virtual machine to its corresponding high-priority scheduling queue. If the remaining CPU resources of the virtual machine are not greater than zero, add the virtual CPU of the virtual machine to its corresponding low-priority scheduling queue. The scheduling module prioritizes scheduling virtual CPUs from the high-priority scheduling queues of each virtual machine to run on the physical CPU.
[0010] Optionally, the scheduling module is further configured to: Monitor the remaining CPU resources of each virtual machine in each control cycle; If any virtual machine task is in a ready state, check if there is any idle physical CPU. If there is available physical CPU, check the remaining CPU resources of the virtual machine; If the virtual machine has more than zero remaining CPU resources, allocate the virtual CPU of the virtual machine to an idle physical CPU to run.
[0011] Optionally, the service quality monitoring module is specifically used for: By using the extended Berkeley Packet Filter eBPF probe, monitor the number of deadline defaults for real-time tasks within this virtual machine in each control cycle; Aggregate the stress information of all real-time tasks on the same virtual CPU to obtain the intermediate stress value corresponding to that virtual CPU. The intermediate stress values of all virtual CPUs within this virtual machine are aggregated to obtain the stress index of this virtual machine, and the stress index is written to a memory area shared with the host machine for the host machine to read at the end of each control cycle.
[0012] Optionally, the service quality monitoring module is specifically used for: The extended Berkeley Packet Filter eBPF probe is used to obtain the run queue length and / or wait time of common tasks within this virtual machine in each control cycle. The stress information for each general task is determined based on the length of the running queue and / or the waiting time. Aggregate the stress information of all general tasks on the same virtual CPU to obtain the intermediate stress value corresponding to that virtual CPU. The intermediate stress values of all virtual CPUs within this virtual machine are aggregated to obtain the stress index of this virtual machine, and the stress index is written to a memory area shared with the host machine for the host machine to read at the end of each control cycle.
[0013] Optionally, the shared memory stores a monotonically increasing version counter; the service quality monitoring module is further configured to increment the version counter each time the stress indicator is written to the shared memory. The resource quota determination module is specifically used for: At the end of each control cycle, the current value of the version counter is read as the first version number; Read the stress metrics of each virtual machine from the shared memory; After completing the reading of the stress indicators for each virtual machine, the current value of the version counter is read as the second version number; If the first version number is equal to the second version number, the stress indicators of each virtual machine read this time are determined to be valid; If the first version number is not equal to the second version number, the stress indicators of each virtual machine read this time are determined to be invalid, and the stress indicators of each virtual machine are read again from the shared memory.
[0014] In a second aspect, embodiments of the present invention provide a QoS-driven virtual CPU scheduling method for satellite ground stations, applied to the system described in the first aspect, comprising: Monitor the stress information of each task within this virtual machine, and aggregate the stress information of multiple tasks within this virtual machine into a stress index for this virtual machine; wherein, the stress index is used to characterize the CPU resource requirements of the corresponding virtual machine; At the end of each control cycle, CPU resources available for the next control cycle are allocated to each virtual machine based on the weight of its stress index. Within each control cycle, based on the CPU resources allocated to each virtual machine within that control cycle, the virtual CPUs of each virtual machine are scheduled to run on the physical CPUs.
[0015] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects: This invention, through a service quality monitoring module within the virtual machine, aggregates task-level pressure information into pressure indicators characterizing the resource demand of the virtual machine. This transforms the CPU resource allocation on the host side from traditional load balancing to task-demand driven allocation. At the end of each control cycle, a resource quota determination module performs differentiated resource allocation based on the weight of each virtual machine's pressure indicator. The scheduling module executes virtual CPU scheduling according to the quota within the cycle. This not only achieves differentiated CPU resource protection centered on task QoS, effectively reducing the risk of deadline defaults for critical tasks during satellite transit windows, but also constructs a semantic mapping between task-level QoS and physical resource scheduling through pressure indicators, alleviating the problem of two-layer scheduling mismatch. Therefore, this invention enables host-side CPU scheduling to directly respond to the task QoS status within the virtual machine, transforming resource allocation logic from general load balancing to task-driven allocation oriented to business needs. This ensures computing power for critical tasks during satellite transit windows, significantly reduces deadline default risks, and meets the service quality requirements in satellite-to-ground interaction scenarios. Attached Figure Description
[0016] Figure 1 This is a schematic diagram of the architecture of a QoS-driven virtual CPU scheduling system for satellite ground stations provided in one embodiment of the present invention; Figure 2 This is a timing diagram illustrating the interaction between the host machine and the virtual machine in one embodiment of the present invention; Figure 3 This is a schematic diagram of the dual-queue scheduling process of the scheduling module in one embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the steps of a QoS-driven virtual CPU scheduling method for satellite ground stations provided in an embodiment of the present invention. Detailed Implementation
[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0018] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.
[0019] The following description, in conjunction with the accompanying drawings, details a QoS-driven virtual CPU scheduling system and method for satellite ground stations provided by the present invention through specific embodiments and application scenarios.
[0020] Figure 1 This is a schematic diagram of the architecture of a QoS-driven virtual CPU scheduling system for satellite ground stations according to an embodiment of the present invention, including a host machine and multiple virtual machines running on the host machine (e.g., Figure 1 (Virtual Machine 1, Virtual Machine 2, and Virtual Machine 3 shown). The virtual machine includes: The service quality monitoring module is used to monitor the stress information of each task within this virtual machine and aggregate the stress information of multiple tasks within this virtual machine into a stress index for this virtual machine; wherein, the stress index is used to characterize the CPU resource requirements of the corresponding virtual machine.
[0021] Figure 2 This is a timing diagram illustrating the interaction between the host machine and the virtual machine in one embodiment of the present invention. Please refer to [link / reference]. Figure 2In this embodiment, each virtual machine (VM) is equipped with a service quality monitoring module. This module is responsible for real-time collection and monitoring of service quality-related data for all tasks running within the VM. Specifically, the service quality monitoring module can obtain key performance indicators (KPIs) for each task during its execution through various observation methods, such as kernel observation mechanisms or statistical interfaces provided by the operating system. These KPIs reflect whether the task is currently in a healthy execution state. Based on this, the service quality monitoring module aggregates the individual stress information of multiple tasks within the VM, ultimately forming a stress indicator that represents the overall resource strain of the VM. The magnitude of the stress indicator represents the VM's urgent need for CPU resources; a higher stress value indicates a greater threat to the service quality of tasks within the VM, and a more urgent need for CPU resources.
[0022] The host machine includes: The resource quota determination module is used to allocate CPU resources available for the next control cycle to each virtual machine based on the weight of each virtual machine's stress index at the end of each control cycle.
[0023] At the host level, a resource quota determination module is implemented. This module is triggered at the end of each preset control cycle. At the end of each control cycle, the resource quota determination module collects stress metrics reported by the service quality monitoring modules of each virtual machine. Based on these stress metrics, the module calculates the weight of each virtual machine's stress metric within the total stress metric of all virtual machines to fairly and selectively allocate CPU resource quotas available for use in the next control cycle to each virtual machine. This ensures that resources are allocated to virtual machines with higher service quality pressure and more urgent needs, thereby achieving efficient resource utilization and prioritizing critical tasks.
[0024] The scheduling module is used to schedule the virtual CPUs of each virtual machine to run on the physical CPUs within each control cycle, based on the CPU resources allocated to each virtual machine within that control cycle.
[0025] Please see Figure 2The host machine also includes a scheduling module. This module, within each control cycle, determines the CPU resource quota allocated to each virtual machine by the resource quota determination module and executes scheduling actions accordingly. The scheduling module allocates the virtual CPUs of each virtual machine to physical CPU cores according to their corresponding quotas. During execution, the scheduling module ensures that the actual CPU time consumed by each virtual machine within a control cycle does not exceed its allocated quota. This transforms the macro-level allocation decisions of the resource quota determination module into micro-level executable scheduling instructions, ultimately achieving control over the use of virtual machine CPU resources.
[0026] By monitoring and aggregating service quality within the virtual machine, calculating periodic quotas based on pressure weights on the host side, and scheduling execution based on quotas, this invention constructs a complete closed-loop control system. It can dynamically perceive the runtime status of virtual machines and quantify the perception results as the basis for scheduling decisions, thereby providing differentiated service guarantees for virtual machines with different business needs within a shared physical resource environment.
[0027] In one optional implementation, the service quality monitoring module is further configured to monitor the transit status information of the virtual machine; the transit status information is used to characterize whether the corresponding virtual machine is in the transit period of a satellite.
[0028] In addition to monitoring task load information within the virtual machine, the service quality monitoring module is also configured to monitor the transit status information of the virtual machine in real time. Transit status information indicates whether the corresponding virtual machine is currently within a critical satellite transit period. Since the business value of satellite ground station tasks is highly concentrated during the satellite transit window, the tasks carried by virtual machines running during this period typically have strict real-time requirements and uninterrupted business continuity needs. Therefore, identifying the transit status of virtual machines is crucial for implementing differentiated resource assurance.
[0029] The resource quota determination module is specifically used for: At the end of each control cycle, based on the transit status information of each virtual machine, the critical virtual machines currently in the satellite transit period are identified, and a minimum guarantee quota is allocated to each critical virtual machine.
[0030] On the host side, at the end of each control cycle, the resource quota determination module first collects the transit status information of all virtual machines and identifies the critical virtual machines currently in the satellite transit period. For these identified critical virtual machines, the resource quota determination module allocates a minimum guaranteed quota. The minimum guaranteed quota is a basic resource guarantee designed to ensure that critical virtual machines, even under conditions of system resource scarcity, have sufficient CPU computing power to maintain their basic operation, thereby avoiding business interruption or severe degradation of service quality due to complete resource shortage. This minimum guarantee mechanism reflects a high priority protection for missions during the satellite transit window.
[0031] The remaining CPU resources to be allocated are determined based on the difference between the total available CPU resources and all allocated minimum guaranteed quotas.
[0032] The resource quota determination module further calculates the difference between the total available CPU resources and the sum of all allocated minimum guaranteed quotas within a control cycle. This difference represents the remaining CPU resources to be allocated. These resources will be re-allocated based on the actual needs of each virtual machine (including critical and non-critical virtual machines) to maximize resource utilization efficiency.
[0033] Based on the stress index of each virtual machine, the remaining CPU resources to be allocated are distributed proportionally to each virtual machine to determine the CPU resources allocated to each virtual machine in the next control cycle; among them, the virtual machine with higher service quality pressure will receive more remaining CPU resources to be allocated.
[0034] The allocation of remaining CPU resources is based on the service quality stress indicators of each virtual machine. The resource quota determination module reads the stress indicator values reported by all virtual machines at the end of the current control cycle. These indicators reflect the urgency of CPU resource requirements for tasks within each virtual machine. Based on this, the module allocates the remaining CPU resources proportionally to all virtual machines according to the stress indicators of each virtual machine. In other words, the virtual machine with higher service quality stress receives a higher weight in the remaining resource allocation, thus receiving more additional CPU resources. This stress-based allocation mechanism ensures that resources are dynamically tilted towards the virtual machines with the most urgent needs, effectively alleviating resource bottlenecks for high-stress virtual machines and improving the overall system's service quality and task completion rate.
[0035] In one optional implementation, the service quality monitoring module is used to: Obtain the number of time-overdue violations for each real-time task within this virtual machine, and determine the stress information for each real-time task based on the number of time-overdue violations.
[0036] The service quality monitoring module is configured to provide fine-grained awareness of the running status of different types of tasks within the virtual machine, in order to quantify the actual demand of each task on central processing unit resources. Since the satellite ground station virtualization environment simultaneously runs real-time tasks with deadline constraints and general-purpose tasks with throughput as the target, the service quality measurement standards for these two types of tasks differ fundamentally. Therefore, differentiated monitoring methods are needed to obtain their stress information separately.
[0037] For real-time tasks employing real-time scheduling strategies (such as the SCHED_DEADLINE strategy in the Linux kernel), the core quality of service (QoS) requirement lies in whether the task can complete execution before the specified deadline within each scheduling cycle. If a task fails to complete before the deadline, a deadline default event occurs, and the cumulative number of these events directly reflects the degree of imbalance between current computing power supply and task demand. The QoS monitoring module obtains the number of deadline defaults for each real-time task within a given time window through kernel observation mechanisms (such as the extended Berkeley packet filter eBPF probe or the kernel scheduling statistics interface), and uses this number as the basis for the stress information of that real-time task. The more defaults, the greater the QoS threat faced by the task, and the more urgent its demand for CPU resources.
[0038] Obtain the run queue length or waiting time of each general task within this virtual machine, and determine the pressure information of each general task based on the run queue length or the waiting time.
[0039] For general computing or background processing tasks running using a generic scheduling policy (such as the Completely Fair Scheduler (CFS), these tasks typically lack explicit deadline constraints, and their execution performance is primarily limited by the congestion level of the CPU run queue. When a task is ready to execute, its queue length and waiting time directly reflect the CPU resource pressure. The Quality of Service (QoS) monitoring module obtains metrics such as the run queue length or average waiting time of each general task's virtual CPU by reading scheduling statistics maintained by the operating system kernel (e.g., via the / proc filesystem or eBPF probes mounted on scheduling points). Higher values indicate more severe latency due to resource contention and a greater demand on CPU resources.
[0040] The stress information of all real-time tasks and all general tasks on this virtual machine are aggregated to obtain the stress index of this virtual machine.
[0041] The service quality monitoring module fuses the two types of heterogeneous stress information mentioned above, and through normalization and weighted combination, finally obtains a single stress indicator that comprehensively reflects the overall resource stress level of the virtual machine. This stress indicator combines the urgency of real-time tasks with the load pressure of general tasks, providing a unified and quantitative input basis for subsequent quota allocation decisions on the host side. In this way, the service quality monitoring module achieves accurate state awareness in complex task-mixing scenarios within the virtual machine, ensuring that the service quality requirements of different types of tasks are effectively included in the resource scheduling considerations.
[0042] In one optional implementation, the service quality monitoring module is specifically used for: By using the extended Berkeley Packet Filter eBPF probe, monitor the number of deadline defaults for real-time tasks within this virtual machine during each control cycle.
[0043] The Quality of Service (QoS) monitoring module is specifically configured to employ a low-overhead observation technique based on Extended Berkeley Packet Filter (eBPF) to accurately capture and statistically analyze deadline default events for real-time tasks within the virtual machine. eBPF, a programmable mechanism running in a kernel-controlled sandbox environment, allows for the secure and efficient mounting of probes to observe the kernel's runtime status without modifying kernel source code or loading kernel modules. The QoS monitoring module utilizes this technology to deploy eBPF probes on the virtual machine kernel's scheduling critical paths, such as attaching them to kernel functions or tracepoints related to real-time task scheduling. When a task within the virtual machine using a real-time scheduling strategy such as SCHED_DEADLINE defaults on its deadline within a control cycle, the eBPF probe can immediately capture the event and accurately record the number of defaults. By summarizing the counts reported by these eBPF probes at the end of each control cycle, the QoS monitoring module can obtain the number of deadline defaults for each real-time task within that cycle, thus forming the initial stress information for that task.
[0044] The stress information of all real-time tasks on the same virtual CPU is aggregated to obtain the intermediate stress value corresponding to that virtual CPU.
[0045] After obtaining the number of deadline defaults for each real-time task, the service quality monitoring module performs the first-level aggregation operation. Since virtual CPUs are the basic unit of scheduling and resource allocation on the host side, aggregating task pressure information by virtual CPU dimension facilitates subsequent integration with the host-side scheduling mechanism. The service quality monitoring module identifies the virtual CPU to which each real-time task belongs, and accumulates or weighted sums the number of deadline defaults for all real-time tasks belonging to the same virtual CPU to obtain the intermediate pressure value corresponding to that virtual CPU. The intermediate pressure value characterizes the overall resource stress of the real-time tasks carried on that virtual CPU.
[0046] The intermediate stress values of all virtual CPUs within this virtual machine are aggregated to obtain the stress index of this virtual machine, and the stress index is written to a memory area shared with the host machine for the host machine to read at the end of each control cycle.
[0047] Furthermore, the service quality monitoring module performs a second-level aggregation operation, which merges the intermediate stress values of all virtual CPUs within the virtual machine to obtain a final stress indicator that represents the overall resource demand of the entire virtual machine. The aggregation process can be a simple summation of the intermediate stress values of each virtual CPU, or a weighted summation based on the importance or business characteristics of tasks on different virtual CPUs. Through this hierarchical aggregation method, the service quality monitoring module transforms scattered, low-level task-level deadline default events into a numerical indicator that macroscopically reflects the overall service quality pressure of the virtual machine—that is, a stress indicator.
[0048] Please see Figure 2 Finally, the service quality monitoring module writes the calculated virtual machine stress metrics into a pre-established memory region shared with the host machine. Shared memory regions are an efficient cross-domain communication mechanism that allows virtual machines and the host machine to exchange data with extremely low latency without frequently triggering virtual machine exits or crashing into the host kernel.
[0049] In one optional implementation, the service quality monitoring module is specifically used for: The extended Berkeley Packet Filter eBPF probe is used to obtain the run queue length and / or wait time of common tasks within this virtual machine during each control cycle.
[0050] The Quality of Service (QoS) monitoring module is configured to monitor a large number of general-purpose computing tasks running within the virtual machine. It employs a low-overhead observation technique based on the Extended Berkeley Packet Filter (eBPF) to obtain load metrics reflecting the resource contention levels of these tasks. General-purpose tasks are typically managed using general scheduling policies such as the Completely Fair Scheduler (CFS), which lack explicit deadline constraints. QoS is primarily reflected in task readiness time and response latency. Therefore, the congestion level of the run queue becomes a key indicator of the resource demand pressure of general-purpose tasks. The QoS monitoring module uses eBPF probes mounted on the critical scheduling path of the virtual machine kernel, executing probe programs, for example, when tasks are enqueued, dequeued, or when the scheduling clock ticks. This allows for real-time collection of the run queue length and waiting time of each general-purpose task on the virtual CPU. By statistically summarizing this collected data within each control cycle, the QoS monitoring module obtains the initial pressure information for each general-purpose task within that cycle. A longer run queue and longer waiting time indicate more intense resource contention for the task, and thus higher CPU resource demand.
[0051] The stress information for each general task is determined based on the length of the run queue and / or the waiting time.
[0052] The service quality monitoring module converts these basic indicators into task-level stress information that can be uniformly quantified, based on preset weighting coefficients or mapping functions. The conversion process may normalize the original observations so that subsequent aggregation operations can integrate indicators with different dimensions. For example, queue length and waiting time may be weighted and combined into a comprehensive stress value; the higher the stress value, the more severe the service quality impairment for that task.
[0053] By aggregating the stress information of all general tasks on the same virtual CPU, the intermediate stress value corresponding to that virtual CPU can be obtained.
[0054] Similar to the previously described embodiment, the service quality monitoring module performs a first-level aggregation operation. The service quality monitoring module identifies the virtual CPU to which each general task belongs, and accumulates or weighted sums the pressure information of all general tasks belonging to the same virtual CPU to obtain the intermediate pressure value corresponding to that virtual CPU. The intermediate pressure value comprehensively reflects the overall load pressure and resource strain of general tasks on that virtual CPU.
[0055] The intermediate stress values of all virtual CPUs within this virtual machine are aggregated to obtain the stress index of this virtual machine, and the stress index is written to a memory area shared with the host machine for the host machine to read at the end of each control cycle.
[0056] The service quality monitoring module performs a second-level aggregation operation, which merges the intermediate stress values of all virtual CPUs within the virtual machine to obtain a final stress indicator that represents the overall resource demand of the entire virtual machine. Through a hierarchical processing method of aggregation, the service quality monitoring module transforms the scattered, low-level task-level run queue status into a numerical indicator that can macroscopically reflect the overall service quality stress of the virtual machine.
[0057] In one optional implementation, the shared memory stores a monotonically increasing version counter; the service quality monitoring module is further configured to increment the version counter each time the stress indicator is written to the shared memory.
[0058] To address potential concurrent access consistency issues during data exchange between virtual machines and the host machine via shared memory, particularly to prevent data tearing or inconsistent intermediate states caused by the virtual machine simultaneously updating data while the host machine is reading stress metrics, this invention introduces a version counter-based synchronization mechanism into the shared memory communication mechanism. Specifically, a monotonically increasing version counter is maintained in the shared memory region to identify the update status of the shared dataset. The service quality monitoring module is further configured to immediately increment the version counter after each calculation of the virtual machine stress metrics and its writing to shared memory.
[0059] The resource quota determination module is specifically used for: At the end of each control cycle, the current value of the version counter is read as the first version number.
[0060] Please see Figure 1 and Figure 2 At the end of each control cycle, the resource quota determination module in the host machine needs to read the stress indicators of each virtual machine from shared memory to perform quota calculations. To ensure the integrity and consistency of the read data, the resource quota determination module executes a verification process based on a version counter. Specifically, the resource quota determination module first reads the current value of the version counter from shared memory and records this value as the first version number.
[0061] Read the stress metrics of each virtual machine from the shared memory.
[0062] The resource quota determination module begins sequentially reading stress metric data from all virtual machines in shared memory. Because shared memory access may span multiple memory cycles, and virtual machines may concurrently update data during the reading process, there is a risk that the directly read data may be partially overwritten.
[0063] After completing the reading of the stress indicators for each virtual machine, the current value of the version counter is read as the second version number.
[0064] Please see Figure 2 After completing the reading of all virtual machine stress metrics, the resource quota determination module reads the current value of the version counter again and records the value read this time as the second version number.
[0065] If the first version number is equal to the second version number, the stress metrics of each virtual machine read this time are determined to be valid.
[0066] Please see Figure 2 After completing the two version number reads, the resource quota determination module compares the first version number with the second version number. If they are equal, it indicates that no new data write operations from the virtual machine occurred during the entire stress metric reading process, meaning the version counter was not incremented. Therefore, it can be confirmed that all stress metric data read this time was obtained within a stable time window that has not been concurrently modified, thus determining that this batch of data is valid data and can be used for subsequent quota calculations.
[0067] If the first version number is not equal to the second version number, the stress indicators of each virtual machine read this time are determined to be invalid, and the stress indicators of each virtual machine are read again from the shared memory.
[0068] Conversely, if the first version number and the second version number are not equal, it indicates that during the process of the resource quota determination module reading the stress indicators, a virtual machine completed a new stress indicator update and incremented the version counter. This means that the data read this time may be incomplete, a mixture of old and new data, or at risk of data tearing, and is therefore judged as invalid data. In this case, please refer to [link to relevant documentation]. Figure 2 The resource quota determination module will discard the results of this read and re-execute the entire read process, starting again from reading the first version number until a set of valid pressure indicator data corresponding to the stable version number is successfully obtained. Through this version counter-based verification and retry mechanism, this invention ensures data consistency in lock-free concurrent access to shared memory scenarios, ensuring that the resource quota determination module always makes scheduling decisions based on accurate and complete pressure information, thereby improving the robustness and reliability of the entire system.
[0069] In one optional implementation, the scheduling module is configured to: Monitor the remaining CPU resources of each virtual machine in each control cycle.
[0070] The scheduling module is configured to perform quota-based scheduling control within the host operating system to ensure that each virtual machine runs within its allocated CPU resource quota, thereby achieving service quality-driven resource guarantees. The core responsibility of the scheduling module is to translate the CPU resource quotas calculated for each virtual machine by the resource quota determination module at the beginning of each control cycle into actual executable scheduling behavior, and to accurately track and dynamically control the consumption of quotas.
[0071] When scheduling any virtual CPU of any virtual machine to run on a physical CPU, the maximum runtime of this scheduling is determined based on the remaining CPU resources of the virtual machine in the current control period; the less remaining CPU resources the virtual machine has in the current control period, the shorter the maximum runtime allocated to its virtual CPU.
[0072] The scheduling module internally maintains the remaining CPU resource status of each virtual machine within the current control cycle. These remaining CPU resources are continuously consumed as the virtual machines actually run. When the scheduling module prepares to schedule a virtual CPU of a virtual machine to a physical CPU core for execution, it first queries the remaining CPU resources of that virtual machine within the current control cycle. Based on these remaining CPU resources, the scheduling module determines the maximum duration for which the virtual CPU can run continuously during this scheduling. The core principle is that the fewer remaining CPU resources a virtual machine has, the shorter the maximum runtime allocated to that virtual CPU in a single session will be. This dynamic adjustment strategy has multiple advantages: Firstly, it prevents virtual machines from rapidly exhausting their quota through a single long burst of execution when their remaining quota is low, thus avoiding the impact on task execution due to sudden resource interruptions. Secondly, by shortening the runtime in a single session, it achieves smooth quota degradation, allowing virtual machines to still obtain brief and frequent execution opportunities when their quota is about to be exhausted, maintaining basic transaction processing capabilities. Furthermore, this fine-grained duration control also helps improve resource switching efficiency in multi-virtual machine concurrent scenarios and reduces scheduling delays for other virtual machines caused by a single virtual machine occupying the CPU for an extended period.
[0073] When the virtual CPU starts running, record the start timestamp of this run; when the virtual CPU stops running, record the end timestamp of this run.
[0074] The scheduling module will perform the actual scheduling operation, allocating the virtual CPU to the physical CPU for execution. Simultaneously, the scheduling module initiates a precise runtime accounting process. Specifically, at the instant the virtual CPU begins execution, the scheduling module records the current moment as a start timestamp. Subsequently, when the virtual CPU stops running due to time slice exhaustion, preemption by a higher-priority task, or voluntarily relinquishing its CPU, the scheduling module again records the current moment as an end timestamp. By subtracting the start timestamp from the end timestamp, the scheduling module can calculate the actual duration of this execution.
[0075] The actual duration of this run is calculated based on the start timestamp and the end timestamp, and the quota value corresponding to the actual duration of this run is deducted from the remaining CPU resources of the virtual machine in the current control cycle.
[0076] The quota value corresponding to the actual duration of the current run is atomically deducted from the virtual machine's remaining CPU resources within the current control cycle. This ensures that the virtual machine's resource consumption matches its actual physical CPU usage time, thereby guaranteeing the accuracy and fairness of quota control. Through the control mechanism of pre-run time limits, in-run accounting, and post-run deduction in this invention, the scheduling module can accurately constrain the CPU resource usage of each virtual machine within each control cycle, ensuring that its actual consumption does not exceed the allocated quota, and transforming service quality pressure perception into priority scheduling and resource allocation for high-pressure virtual machines.
[0077] In one alternative implementation, each virtual machine is configured with a high-priority scheduling queue and a low-priority scheduling queue.
[0078] The scheduling module configures a high-priority scheduling queue and a low-priority scheduling queue for each virtual machine in the host operating system. These two scheduling queues serve as core data structures in an extensible scheduling framework (e.g., based on sched_ext), used to perform differentiated queuing management of the virtual CPUs based on the virtual machine's remaining CPU resource status within the current control cycle.
[0079] The scheduling module is also used for: Monitor the remaining CPU resources of each virtual machine in each control cycle; check for idle physical CPUs when any virtual machine's task is in a ready state.
[0080] As mentioned earlier, the scheduling module maintains the amount of CPU resources remaining for each virtual machine in the current control cycle. The remaining CPU resources are dynamically consumed as the virtual machine actually runs, reflecting the CPU time budget that the virtual machine can still use in the current cycle. Figure 3This is a flowchart illustrating the dual-queue scheduling process of the scheduling module in one embodiment of the present invention. Please refer to [link / reference]. Figure 3 When any virtual machine's internal task is in a ready state, meaning that a virtual CPU of that virtual machine is ready to run and waiting to be scheduled to a physical CPU for execution, the scheduling module first checks whether there are any idle physical CPU cores in the current system. If there are idle physical CPUs, the virtual CPU can be directly scheduled to run on that idle core.
[0081] If there are no idle physical CPUs, check the remaining CPU resources of the virtual machine; if the remaining CPU resources of the virtual machine are greater than zero, add the virtual CPU of the virtual machine to its corresponding high-priority scheduling queue; if the remaining CPU resources of the virtual machine are not greater than zero, add the virtual CPU of the virtual machine to its corresponding low-priority scheduling queue.
[0082] However, in common scenarios where system load is high and all physical CPUs are occupied, no idle physical CPUs are available for direct scheduling. In such cases, please refer to [link to relevant documentation]. Figure 3 The scheduling module makes further queuing decisions based on the virtual machine's remaining CPU resources within the current control cycle. Specifically, the scheduling module checks if the virtual machine's remaining CPU resources are greater than zero. If the remaining resources are greater than zero, it indicates that the virtual machine still has available CPU quota, and its task should be given priority. Therefore, the scheduling module adds the virtual machine's virtual CPU to its corresponding high-priority scheduling queue to await scheduling. Conversely, if the virtual machine's remaining CPU resources are no greater than zero, meaning its quota has been exhausted within the current cycle, the scheduling module adds the virtual machine's virtual CPU to its corresponding low-priority scheduling queue, waiting for potentially available idle resources in a "best effort" manner.
[0083] The scheduling module prioritizes scheduling virtual CPUs from the high-priority scheduling queues of each virtual machine to run on the physical CPU.
[0084] After completing the enqueueing operation, the scheduling module, when performing scheduling and dispatching, prioritizes selecting virtual CPUs from the high-priority scheduling queues of each virtual machine and assigns them to physical CPUs for execution. Only when all high-priority queues are empty will the scheduling module consider selecting virtual CPUs from low-priority queues for scheduling. This priority-based queue selection mechanism ensures that virtual machines with remaining quotas have a higher chance of execution than virtual machines whose quotas have been exhausted. Thus, in scenarios with intense resource competition, CPU resources are allocated to virtual machines with greater service quality pressure and more urgent needs.
[0085] In an optional implementation, the scheduling module is further configured to: Monitor the remaining CPU resources of each virtual machine in each control cycle; check for idle physical CPUs when any virtual machine's task is in a ready state.
[0086] The specific implementation methods described here are equivalent to or similar to those described above, so please refer to the previous text; they will not be repeated here.
[0087] If there are available physical CPUs, check the remaining CPU resources of the virtual machine.
[0088] Please see Figure 3 After confirming the existence of idle physical CPUs, the scheduling module further checks the virtual machine's remaining CPU resources. Even if idle physical CPUs are available, if the virtual machine has exhausted its remaining CPU resources within the current control cycle—that is, its quota has been used up—directly scheduling it for execution would cause the virtual machine to over-quota resource usage, thereby disrupting the entire resource guarantee system based on quality of service. Therefore, the scheduling module will only allow the virtual machine to immediately execute using idle physical CPUs if it confirms that the virtual machine's remaining CPU resources are greater than zero.
[0089] If the virtual machine has more than zero remaining CPU resources, allocate the virtual CPU of the virtual machine to an idle physical CPU to run.
[0090] Please see Figure 3 When both of the above conditions are met—that is, there are idle physical CPUs and the virtual machine's remaining CPU resources are greater than zero—the scheduling module performs a scheduling operation, directly allocating the virtual CPU of the virtual machine to an idle physical CPU core to start running. This skips the conventional path of adding the virtual CPU to the scheduling queue and prioritizing it, thereby minimizing scheduling overhead and task waiting time. In this way, the system can provide near-zero-latency scheduling services for ready tasks with quotas when under low load or with ample resources, ensuring quota control and improving the overall system efficiency.
[0091] It should be noted that, in order to ensure the stability of the entire virtualization platform while introducing a scalable scheduling mechanism, when the customized scheduling module implemented based on the scalable scheduling framework in the host operating system malfunctions, the system can automatically and smoothly switch back to the default general scheduler, thereby avoiding the entire host system or the virtual machine instances running on it from crashing or experiencing severe performance degradation due to the failure of the scheduling extension module.
[0092] Specifically, this invention preferably employs a scalable scheduling framework (e.g., sched_ext) based on extended Berkeley Packet Filter (eBPF) technology to implement host-side QoS-aware scheduling. This framework allows the scheduling module to run in a secure sandbox, and its executed eBPF bytecode is verified by the kernel, inherently restricting dangerous operations such as illegal memory access and infinite loops. However, despite these security safeguards, complex scheduling logic can still malfunction for various reasons, such as eBPF program execution timeouts, triggering illegal operations undetected by the kernel verifier, or inherent defects in the scheduling logic itself leading to infinite loops or resource leaks. To address these potential risks, this application constructs a multi-level fallback protection system.
[0093] In its implementation, the kernel framework continuously monitors the execution process of the scalable scheduler when it starts running. When an anomaly is detected, such as an eBPF scheduler exceeding a preset safety threshold or attempting a prohibited operation, the kernel immediately triggers a rollback process. The core action of this rollback process is to seamlessly switch the current CPU core's scheduling policy from the scalable scheduling class back to the operating system's default scheduling class, such as the Completely Fair Scheduler (CFS).
[0094] During the rollback mechanism, the first step is to suspend the currently malfunctioning scheduling extension module and clean up its occupied resources. Then, the kernel brings all virtual CPU threads previously managed by the scalable scheduler back under the management of the default scheduler. These threads are added back to the default scheduler's run queue based on their original scheduling parameters and priorities, and continue to receive execution opportunities according to default scheduling policies (such as the fair allocation principle of CFS). Simultaneously, the system records the time, cause, and involved virtual machines and tasks in detail in the kernel logs for subsequent troubleshooting and problem localization by operations and maintenance personnel.
[0095] Figure 4 This is a schematic diagram illustrating the steps of a QoS-driven virtual CPU scheduling method for satellite ground stations according to an embodiment of the present invention, applied to the system described above. Please refer to [link / reference]. Figure 4 ,include: Step S11: Monitor the pressure information of each task within this virtual machine, and aggregate the pressure information of multiple tasks within this virtual machine into a pressure index for this virtual machine; wherein, the pressure index is used to characterize the degree of CPU resource demand of the corresponding virtual machine.
[0096] Each virtual machine (VM) is equipped with a service quality monitoring (SQM) module, which is responsible for real-time collection and monitoring of service quality-related data for all tasks running within the VM. Specifically, the SQM module uses various observation methods, such as kernel observation mechanisms or statistical interfaces provided by the operating system, to obtain key performance indicators (KPIs) for each task during execution. These KPIs reflect whether the task is currently in a healthy execution state. Based on this, the SQM module aggregates the individual stress information of multiple tasks within the VM, ultimately forming a stress index that represents the overall resource strain of the VM. The magnitude of the stress index indicates the VM's urgent need for CPU resources; a higher stress value indicates a greater threat to the service quality of tasks within the VM, and a more pressing need for CPU resources.
[0097] Step S12: At the end of each control cycle, allocate CPU resources available for use in the next control cycle to each virtual machine according to the weight of each virtual machine's stress index.
[0098] At the host level, a resource quota determination module is implemented. This module is triggered at the end of each preset control cycle. At the end of each control cycle, the resource quota determination module collects stress metrics reported by the service quality monitoring modules of each virtual machine. Based on these stress metrics, the module calculates the weight of each virtual machine's stress metric within the total stress metric of all virtual machines to fairly and selectively allocate CPU resource quotas available for use in the next control cycle to each virtual machine. This ensures that resources are allocated to virtual machines with higher service quality pressure and more urgent needs, thereby achieving efficient resource utilization and prioritizing critical tasks.
[0099] Step S13: In each control cycle, according to the CPU resources allocated to each virtual machine in that control cycle, schedule the virtual CPU of each virtual machine to run on the physical CPU.
[0100] The host machine also includes a scheduling module. This module, within each control cycle, determines the CPU resource quota allocated to each virtual machine by the resource quota determination module and executes scheduling actions accordingly. The scheduling module allocates the virtual CPUs of each virtual machine to physical CPU cores according to their corresponding quotas. During execution, the scheduling module ensures that the actual CPU time consumed by each virtual machine within a control cycle does not exceed its allocated quota. This transforms the macro-level allocation decisions of the resource quota determination module into micro-level executable scheduling instructions, ultimately achieving precise control over the use of virtual machine CPU resources.
[0101] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.
[0102] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.
[0103] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.
Claims
1. A QoS-driven virtual CPU scheduling system for satellite ground stations, characterized in that, This includes the host machine and multiple virtual machines running on the host machine; The virtual machine includes: The service quality monitoring module is used to monitor the stress information of each task within this virtual machine and aggregate the stress information of multiple tasks within this virtual machine into a stress index for this virtual machine; wherein, the stress index is used to characterize the CPU resource requirements of the corresponding virtual machine; The host machine includes: The resource quota determination module is used to allocate CPU resources available for the next control cycle to each virtual machine based on the weight of each virtual machine's stress index at the end of each control cycle. The scheduling module is used to schedule the virtual CPUs of each virtual machine to run on the physical CPUs within each control cycle, based on the CPU resources allocated to each virtual machine within that control cycle.
2. The system according to claim 1, characterized in that, The service quality monitoring module is also used to monitor the transit status information of this virtual machine; the transit status information is used to indicate whether the corresponding virtual machine is in the transit period of a satellite. The resource quota determination module is specifically used for: At the end of each control cycle, based on the transit status information of each virtual machine, the critical virtual machines currently in the satellite transit period are identified, and a minimum guarantee quota is allocated to each critical virtual machine. The remaining CPU resources to be allocated are determined based on the difference between the total available CPU resources and all allocated minimum guaranteed quotas. Based on the stress index of each virtual machine, the remaining CPU resources to be allocated are distributed proportionally to each virtual machine to determine the CPU resources allocated to each virtual machine in the next control cycle; among them, the virtual machine with higher service quality pressure will receive more remaining CPU resources to be allocated.
3. The system according to claim 2, characterized in that, The service quality monitoring module is used for: Obtain the number of time-overdue violations for each real-time task within this virtual machine, and determine the pressure information for each real-time task based on the number of time-overdue violations; Obtain the run queue length or waiting time of each general task within this virtual machine, and determine the pressure information of each general task based on the run queue length or the waiting time; The stress information of all real-time tasks and all general tasks on this virtual machine are aggregated to obtain the stress index of this virtual machine.
4. The system according to claim 1, characterized in that, The scheduling module is used for: Monitor the remaining CPU resources of each virtual machine in each control cycle; When scheduling any virtual CPU of any virtual machine to run on a physical CPU, the maximum runtime of this scheduling is determined based on the remaining CPU resources of the virtual machine in the current control period; the less remaining CPU resources the virtual machine has in the current control period, the shorter the maximum runtime allocated to its virtual CPU. When the virtual CPU starts running, record the start timestamp of this run; when the virtual CPU stops running, record the end timestamp of this run. The actual duration of this run is calculated based on the start timestamp and the end timestamp, and the quota value corresponding to the actual duration of this run is deducted from the remaining CPU resources of the virtual machine in the current control cycle.
5. The system according to claim 1, characterized in that, Each virtual machine is configured with a high-priority scheduling queue and a low-priority scheduling queue; the scheduling module is also used for: Monitor the remaining CPU resources of each virtual machine in each control cycle; If any virtual machine task is in a ready state, check if there is any idle physical CPU. If no physical CPUs are available, check the remaining CPU resources of the virtual machine; If the virtual machine has more than zero remaining CPU resources, add the virtual CPU of the virtual machine to its corresponding high-priority scheduling queue. If the remaining CPU resources of the virtual machine are not greater than zero, add the virtual CPU of the virtual machine to its corresponding low-priority scheduling queue. The scheduling module prioritizes scheduling virtual CPUs from the high-priority scheduling queues of each virtual machine to run on the physical CPU.
6. The system according to claim 5, characterized in that, The scheduling module is also used for: Monitor the remaining CPU resources of each virtual machine in each control cycle; If any virtual machine task is in a ready state, check if there is any idle physical CPU. If there is available physical CPU, check the remaining CPU resources of the virtual machine; If the virtual machine has more than zero remaining CPU resources, allocate the virtual CPU of the virtual machine to an idle physical CPU to run.
7. The system according to claim 3, characterized in that, The service quality monitoring module is specifically used for: By using the extended Berkeley Packet Filter eBPF probe, monitor the number of deadline defaults for real-time tasks within this virtual machine in each control cycle; Aggregate the stress information of all real-time tasks on the same virtual CPU to obtain the intermediate stress value corresponding to that virtual CPU. The intermediate stress values of all virtual CPUs within this virtual machine are aggregated to obtain the stress index of this virtual machine, and the stress index is written to a memory area shared with the host machine for the host machine to read at the end of each control cycle.
8. The system according to claim 3, characterized in that, The service quality monitoring module is specifically used for: The extended Berkeley Packet Filter eBPF probe is used to obtain the run queue length and / or wait time of common tasks within this virtual machine in each control cycle. The stress information for each general task is determined based on the length of the running queue and / or the waiting time. Aggregate the stress information of all general tasks on the same virtual CPU to obtain the intermediate stress value corresponding to that virtual CPU. The intermediate stress values of all virtual CPUs within this virtual machine are aggregated to obtain the stress index of this virtual machine, and the stress index is written to a memory area shared with the host machine for the host machine to read at the end of each control cycle.
9. The system according to claim 7 or 8, characterized in that, The shared memory stores a monotonically increasing version counter; the service quality monitoring module is further configured to increment the version counter each time the stress indicator is written to the shared memory. The resource quota determination module is specifically used for: At the end of each control cycle, the current value of the version counter is read as the first version number; Read the stress metrics of each virtual machine from the shared memory; After completing the reading of the stress indicators for each virtual machine, the current value of the version counter is read as the second version number; If the first version number is equal to the second version number, the stress indicators of each virtual machine read this time are determined to be valid; If the first version number is not equal to the second version number, the stress indicators of each virtual machine read this time are determined to be invalid, and the stress indicators of each virtual machine are read again from the shared memory.
10. A QoS-driven virtual CPU scheduling method for satellite ground stations, characterized in that, Applied to the system as described in any one of claims 1-9, comprising: Monitor the stress information of each task within this virtual machine, and aggregate the stress information of multiple tasks within this virtual machine into a stress index for this virtual machine; wherein, the stress index is used to characterize the CPU resource requirements of the corresponding virtual machine; At the end of each control cycle, CPU resources available for the next control cycle are allocated to each virtual machine based on the weight of its stress index. Within each control cycle, based on the CPU resources allocated to each virtual machine within that control cycle, the virtual CPUs of each virtual machine are scheduled to run on the physical CPUs.