An eBPF-based virtual machine vCPU scheduling contention monitoring method and device

Abstract

The application provides an eBPF-based virtual machine vCPU scheduling contention monitoring method and device, the method comprising: constructing a global hash map protected by a read-copy update mechanism and a local cache corresponding to each physical CPU, and mounting a scheduling event hook and a scheduling Tick hook; when the scheduling event is triggered, updating the statistical increment of the vCPU in the local cache in priority, and updating the global hash map when a miss occurs; synchronizing the statistical increment of the local cache to the global hash map to generate vCPU scheduling contention monitoring data. The application reduces the performance influence of the scheduling statistical operation on the original scheduling process under the premise of meeting the kernel memory quota constraint and not increasing the consumption of system resources, and meets the demand of cloud platform virtualization monitoring.

Description

Technical Field

[0001] This application belongs to the field of virtualization technology and kernel monitoring technology, and in particular relates to a virtual machine vCPU scheduling contention monitoring method and device based on eBPF. Background Technology

[0002] Existing eBPF-based virtual machine vCPU scheduling contention monitoring solutions typically use a global hash map to store statistical data for all vCPUs, and employ spinlocks or read-copy update mechanisms to protect against concurrent access. Each time a scheduling event is triggered, the global hash map needs to be accessed to update the statistics, a process involving three types of operations: hash key calculation, hash bucket traversal, and cross-core memory access. In high-concurrency scheduling scenarios, the cumulative overhead of these operations increases with event density, lengthening the execution time of scheduling hooks and impacting the native scheduling process. Reducing the frequency of global access by using a local cache of all data would consume a large amount of kernel memory, exceeding the memory quota limit of the eBPF program. Furthermore, the synchronous maintenance of all data requires additional timer components, increasing system resource consumption and making it difficult to optimize statistical performance with minimal intrusion. Summary of the Invention

[0003] To address the issue of reducing the performance impact of scheduling statistics operations on the native scheduling process while satisfying kernel-mode memory quota constraints and without increasing system resource consumption, this application provides a virtual machine vCPU scheduling contention monitoring method and apparatus based on eBPF.

[0004] This application first provides a virtual machine vCPU scheduling contention monitoring method based on eBPF, including: A global hash map protected by a read-copy-update mechanism and the local cache corresponding to each physical CPU are constructed, and scheduling event hooks and scheduling Tick hooks are attached. The read-copy-update mechanism provides a synchronization mechanism for the kernel to protect concurrent access. In response to a scheduling event, the statistical increment of the corresponding vCPU is updated in the local cache of the current physical CPU first. If the local cache is not hit, the global hash mapping is updated. In response to a scheduling Tick interrupt, the vCPU popularity ranking in the local cache is updated and the cache entries are adjusted. The statistical increments of the local cache are synchronized to the global hash map, and vCPU scheduling contention monitoring data is generated based on the statistical data of the global hash map.

[0005] Optionally, in response to a scheduling event, the corresponding vCPU's statistical increment is updated in the local cache of the current physical CPU first. If the local cache is not hit, the global hash mapping is updated. In response to a scheduling Tick interrupt, the vCPU popularity ranking in the local cache is updated and the cache entries are adjusted, including: parsing the vCPU identifier and metric increment corresponding to the scheduling event, and matching them with the local cache entries of the current physical CPU; accumulating the metric increment in the local cache when a cache entry is hit, and updating the corresponding statistical value of the global hash mapping and accumulating the popularity count of the corresponding vCPU when a cache miss is not hit; and updating the popularity value of each vCPU based on a sliding window and adjusting the cache entries in the local cache in response to a scheduling Tick interrupt.

[0006] Optionally, the construction of the global hash map protected by the read-copy-update mechanism and the local cache corresponding to each physical CPU, and the mounting of scheduling event hooks and scheduling Tick hooks, includes: creating a global hash map; using a read-copy-update mechanism to protect the global hash map from concurrent access; allocating a fixed-length local cache to each physical CPU, wherein the local cache includes a hot entry storage area, a hotness count field, and a free slot linked list; mounting scheduling event hooks to the kernel scheduling tracepoint node, and mounting scheduling Tick hooks to the scheduling Tick interrupt entry of each physical CPU.

[0007] Optionally, synchronizing the statistical increment of the local cache to the global hash map and generating vCPU scheduling contention monitoring data based on the statistical data of the global hash map includes: at the end of the read copy update grace period, accumulating the statistical increment of the local cache of each physical CPU into the corresponding entry of the global hash map; clearing the statistical increment in the local cache, retaining the value of the heat count field; reading the statistical data of the global hash map, and generating vCPU scheduling contention monitoring data by combining the mapping relationship between virtual machine identifier and vCPU identifier.

[0008] Optionally, in response to a scheduling Tick interrupt, updating the heat value of each vCPU based on a sliding window and adjusting the cache entries in the local cache includes: counting the access records of each vCPU in the current Tick cycle and updating the heat count value in the sliding window; removing cache entries with heat values ​​below the eviction threshold from the storage area and adding the corresponding slots to the free slot list; and allocating free slots to non-cache vCPUs with heat values ​​reaching the admission threshold and adding them to the storage area of ​​the local cache.

[0009] Optionally, the step of parsing the vCPU identifier and metric increment corresponding to the scheduling event and matching it with the local cache entry of the current physical CPU includes: extracting the vCPU thread identifier and event type from the context information of the scheduling event, calculating the metric increment corresponding to this event; traversing the hot entry storage area of ​​the local cache using the vCPU thread identifier as the matching key; comparing the consistency of the thread identifier and determining the cache hit status.

[0010] Optionally, the step of accumulating the statistical increment of each physical CPU's local cache to the corresponding entry of the global hash map at the end of the read copy update grace period includes: detecting the grace period status of the read copy update mechanism and confirming that all read-side critical sections have exited; traversing all hot entries of each physical CPU's local cache and extracting the corresponding statistical increment; and writing the statistical increment to the corresponding vCPU entry of the global hash map through an atomic accumulation operation.

[0011] Optionally, the method further includes: in response to the vCPU cross-core migration event, synchronizing the statistical increment of the corresponding vCPU in the local cache of the migrated physical CPU to the global hash map; marking the cache entry of the corresponding vCPU in the migrated physical CPU as pending elimination; and accumulating the heat count of the corresponding vCPU in subsequent scheduling events of the migrated physical CPU, and adding it to the local cache after reaching the admission threshold.

[0012] Optionally, the method further includes: collecting the scheduling event density within a unit window, adjusting the step size of the sliding window according to the scheduling event density; shortening the sliding window step size when the scheduling event density increases, and lengthening the sliding window step size when the scheduling event density decreases.

[0013] This application also provides a virtual machine vCPU scheduling contention monitoring device based on eBPF, including a storage construction module, an event processing module, and a data generation module. The storage construction module is used to construct a global hash map protected by a read-copy-update mechanism and the local cache corresponding to each physical CPU, and to attach scheduling event hooks and scheduling Tick hooks. The event processing module is used to, in response to the triggering of a scheduling event, first update the statistical increment of the corresponding vCPU in the local cache of the current physical CPU, update the global hash map when the local cache is not hit, and update the vCPU popularity ranking in the local cache and adjust the cache entries in response to the triggering of a scheduling Tick interrupt. The data generation module is used to synchronize the statistical increment of the local cache to the global hash map, and generate vCPU scheduling contention monitoring data based on the statistical data of the global hash map.

[0014] In the embodiments provided in this application, a two-level storage architecture is constructed to sink frequently accessed vCPU statistics to the physical CPU local cache. When a scheduling event is triggered, the local cache is accessed first to complete the update, reducing the number of accesses to the global hash mapping. Simultaneously, the local cache is a single-CPU private resource, and the access process does not require concurrent protection operations, reducing the execution overhead of a single statistics session. This application reuses the kernel's native scheduling Tick interrupt to complete the hotspot ranking update, eliminating the need for additional timed triggering components. Furthermore, the update logic runs in the interrupt context, without increasing the execution time of the scheduling event hook, thus avoiding cache maintenance overhead offsetting performance gains. This application combines the grace period of the read-copy update mechanism to complete local incremental synchronization. The synchronization process does not block global read operations, ensuring the convergence of statistical data. The above architecture works together to reduce the impact of scheduling statistics on native scheduling with low system overhead within the kernel memory constraints, while maintaining the accuracy of the statistical data. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart of the virtual machine vCPU scheduling contention monitoring method based on eBPF in the embodiments of this application; Figure 2 This is a flowchart of the scheduling event processing sub-process in the embodiments of this application; Figure 3 This is a flowchart of the storage construction and hook mounting process in the embodiments of this application; Figure 4 This is a flowchart illustrating the data synchronization and monitoring data generation process in this application embodiment; Figure 5 This is a flowchart of the Tick popularity update and cache adjustment process in the embodiments of this application; Figure 6 This is a flowchart of the scheduling event parsing and cache matching process in the embodiments of this application; Figure 7 This is a flowchart of the RCU grace period synchronization process in the embodiments of this application; Figure 8 This is a flowchart of the vCPU cross-core migration process in the embodiments of this application; Figure 9 This is a flowchart of the adaptive sliding window step size adjustment in the embodiments of this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without such specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0018] In this embodiment, the eBPF-based virtual machine vCPU scheduling contention monitoring method runs in the operating system kernel of the cloud platform host machine. It leverages eBPF's programmability to collect relevant data on vCPU scheduling events, statistically analyzes and quantifies the resource contention level of virtual machine vCPUs, and provides data support for cloud platform resource scheduling, load balancing, and performance optimization. The overall operational architecture of this application is divided into a kernel-mode acquisition layer and a user-mode parsing layer. The kernel-mode acquisition layer is responsible for capturing scheduling events, performing local statistics, and aggregating global data. The user-mode parsing layer is responsible for associating virtual machine identifiers with vCPU identifiers, calculating multi-dimensional contention metrics, and outputting monitoring results. The two layers work together to complete the entire monitoring process.

[0019] In the embodiments of this application, such as Figure 1 As shown, the virtual machine vCPU scheduling contention monitoring method based on eBPF includes: S101: Construct a global hash map protected by a read-copy-update mechanism and the local cache corresponding to each physical CPU, attach scheduling event hooks and scheduling Tick hooks, and provide a synchronization mechanism for concurrent access protection for the kernel through read-copy-update. S102: In response to a scheduling event, first update the statistical increment of the corresponding vCPU in the local cache of the current physical CPU. If the local cache is not hit, update the global hash mapping. In response to a scheduling Tick interrupt, update the vCPU popularity ranking in the local cache and adjust the cache entries. S103: Synchronize the statistical increment of the local cache to the global hash map, and generate vCPU scheduling contention monitoring data based on the statistical data of the global hash map.

[0020] Specifically, the global hash map is a kernel-level key-value storage structure used to store full statistical data for all vCPUs. The key of the global hash map is the kernel thread identifier corresponding to the vCPU; each vCPU corresponds to a unique kernel thread, and the thread identifier uniquely identifies the corresponding vCPU. The values ​​of the global hash map include multiple statistical items, specifically including total ready wait time, total kernel preemption time, total scheduling execution time, total blocking wait time, context switch count, preemption count, etc. All statistical items are cumulative values, continuously accumulating with the triggering of scheduling events. A read-copy-update mechanism is used to protect the structural consistency of the global hash map. Structural changes such as adding and deleting hash table nodes follow the read-copy-update execution flow. Read operations do not require acquiring locks throughout, and write operations achieve concurrency safety by copying nodes, updating pointers, and waiting for a grace period to reclaim old nodes. The read-copy-update mechanism is suitable for concurrent scenarios with many reads and few writes. Structural changes to the global hash map are only triggered when a vCPU is created or destroyed, which is a low-frequency operation. Therefore, using the read-copy-update mechanism can minimize the concurrency overhead of read operations while ensuring structural safety.

[0021] Specifically, the local cache is set up independently at the physical CPU level, with each physical CPU corresponding to an independent local cache. The local cache only stores the statistical increments of the vCPUs accessed most frequently on the current physical CPU, and the storage capacity is a fixed length, which can be pre-configured according to the host machine's hardware configuration and business scenarios. The local cache is a private resource of the current physical CPU, and can only be accessed by scheduling event hooks and scheduling tick hooks running on the current physical CPU. There is no scenario of concurrent read and write operations on multiple CPUs, so accessing the local cache does not require any concurrency protection mechanism and can be completed by ordinary memory read and write operations, with execution overhead far lower than the overhead of accessing the global hash map. The local cache stores statistical increments rather than full cumulative values. The increments are the new statistics generated between two synchronization cycles. During synchronization, the increments are simply added to the global hash map, which is logically simple and less prone to data conflicts.

[0022] Specifically, the scheduling event hook is attached to the corresponding node of the kernel scheduling subsystem. When a scheduling-related event occurs in the kernel, the hook is automatically triggered to capture the event's context information and complete statistical updates. The scheduling event hook covers various scheduling events throughout the vCPU's entire lifecycle, including process wake-up events, process ready events, process preemption events, context switching events, and task blocking events. Different types of events correspond to different statistical update logic. The scheduling Tick hook is attached to the native scheduling Tick interrupt entry point of each physical CPU. The scheduling Tick interrupt is a periodic interrupt inherent to the operating system kernel. Each physical CPU is triggered at a fixed frequency to update process time slices, count CPU load, and perform scheduling accounting operations. This is logic that must be executed during kernel operation. Reusing the scheduling Tick interrupt as the trigger time for hot spot ranking updates eliminates the need to create additional timers or work queues, does not increase system resource consumption, and the Tick interrupt runs in an independent interrupt context, separate from the execution path of scheduling events. The hot spot update logic does not increase the execution time of the scheduling event hook.

[0023] Specifically, the processing flow after a scheduling event is triggered is a hot path for scheduling statistics, which directly affects the performance of native scheduling. Therefore, this application decentralizes the statistical operations of high-frequency access to the local cache for execution, minimizing the execution length of the hot path. When a scheduling event occurs, it first attempts to find the corresponding vCPU entry in the local cache of the current CPU. If the lookup is successful, the incremental update is completed directly locally. The entire process involves only local memory access, resulting in fast execution speed and low overhead. If the lookup fails, the global hash map is accessed to complete the statistical update, and the access frequency of that vCPU is recorded for subsequent hot spot ranking calculations. When a scheduling Tick interrupt is triggered, the logic for hot spot ranking update and cache entry adjustment is executed. Cold entries are evicted and new hot spots are added based on the access frequency within the sliding window, ensuring that the entries in the local cache are always the vCPUs with the highest current access frequency, maintaining a high cache hit rate.

[0024] Specifically, the statistical increments in the local cache need to be periodically synchronized to the global hash map to ensure the integrity and convergence of global data. Synchronization is performed at the end of the grace period for read-copy updates, when all CPUs have exited the read-side critical section. Synchronization operations will not conflict with read operations, eliminating the need to block read operations and conforming to the concurrency protection characteristics of read-copy updates. After synchronization, the statistical increments in the local cache are cleared, and the next statistical cycle begins. The heat count value is retained for continuous monitoring of vCPU access heat. The user-space resolution service reads all statistical data from the global hash map according to a preset statistical cycle. Combined with the pre-maintained mapping relationship between virtual machine identifiers and vCPU identifiers, it aggregates the vCPU-level statistical data to the corresponding virtual machines, calculates multi-dimensional contention metrics, and finally generates vCPU scheduling contention monitoring data, which is then output to the monitoring platform or alarm system.

[0025] It should be noted that the secondary storage architecture and hotspot filtering mechanism in this application are adapted to the access distribution characteristics of virtualization scheduling scenarios. In a virtualization environment, the load of different vCPUs varies greatly. A small number of high-load vCPUs generate the vast majority of scheduling events and statistical access requests, while most low-load vCPUs have very low access frequency. Based on this distribution characteristic, only a small number of local cache slots are needed to cover the access requirements of most scheduling events, achieving a significant performance improvement for most accesses with minimal memory overhead. The return on investment aligns with the resource constraints of kernel-mode programs. Furthermore, reusing the kernel's native periodic interrupts for cache maintenance avoids the additional overhead of independent timing components and the performance degradation caused by maintaining the cache in hot paths, ensuring a positive net benefit for the overall solution.

[0026] In the embodiments of this application, such as Figure 3 As shown, the construction of the global hash map protected by the read-copy-update mechanism and the local cache corresponding to each physical CPU, and the attachment of scheduling event hooks and scheduling Tick hooks, includes: S301: Create a global hash map and use a read-copy-update mechanism to protect the global hash map from concurrent access. S302: Allocate a fixed-length local cache to each physical CPU. The local cache includes a hot entry storage area, a hotness count field, and a free slot linked list. S303: Mounts scheduling event hooks to kernel scheduling tracepoint nodes and mounts scheduling tick hooks to the scheduling tick interrupt entry points of each physical CPU.

[0027] Specifically, the creation of the global hash map is completed during the eBPF program loading phase, and is an initialization operation that is executed only once. When creating the global hash map, the length of the key, the length of the value, the maximum number of entries, and the concurrency protection method need to be specified. The key length matches the data length of the kernel thread identifier, ensuring that it can uniquely identify a vCPU thread. The length of the value is determined based on the total length of all statistical items, with each statistical item corresponding to a fixed-length numeric field stored using unsigned long integers to ensure that the statistical range meets the needs of long-term operation and prevents overflow issues. The maximum number of entries is determined based on the maximum number of vCPUs supported by the host machine, reserving sufficient redundancy space to avoid insufficient hash entries during large-scale virtual machine deployments. The concurrency protection method is specified as a read-copy-update mechanism, with the kernel eBPF subsystem providing the corresponding concurrency protection capabilities, eliminating the need for developers to manually implement lock logic.

[0028] Specifically, the read-copy-update mechanism protects the global hash map by first allocating memory for the new node, filling it with key and value data, and then inserting the new node into the hash bucket's linked list using atomic pointer replacement. After insertion, the new node is visible to all subsequent read operations. Operations already in the critical read section before insertion will still access the old linked list structure and will not be affected by the insertion. When deleting a hash node, the node's pointer is removed from the hash linked list. New read operations will no longer access the node, but operations already in the critical read section may still be using its memory. Therefore, the node's memory cannot be immediately reclaimed; a grace period is required to ensure all CPUs have exited the critical read section that might access the node before the node's memory is safely reclaimed. The length of this grace period is automatically managed by the kernel's read-copy-update mechanism, requiring no manual intervention, ensuring all read operations complete safely without accessing reclaimed memory.

[0029] Specifically, the process of allocating a fixed-length local cache to each physical CPU is also completed during the eBPF program loading phase. The local cache adopts a per-CPU storage structure, with the kernel allocating independent memory space to each physical CPU. Each CPU can only access its corresponding portion of memory, naturally achieving CPU-level isolation. The total length of the local cache is configurable, typically set to the order of dozens of entries, which can cover the access needs of most scheduling events, occupying very limited kernel memory, far below the memory quota limit of the eBPF program. The local cache consists of three components: a hotspot entry storage area, a popularity count field, and a free slot linked list. The hotspot entry storage area stores the statistical increments and basic identifiers corresponding to the vCPUs selected as hotspots. Each entry contains a vCPU thread identifier field and multiple statistical increment fields. The field definitions correspond one-to-one with the statistical items in the global hash mapping, ensuring that the increments can be directly accumulated in the global mapping. The popularity count field records the number of times each vCPU is accessed within the sliding window, serving as the basis for hotspot ranking. Each vCPU corresponds to a popularity count value; a higher value indicates a higher access frequency. The free slot list is used to manage unused cache slots. When a new vCPU needs to be added to the cache, a slot is taken from the free slot list for use. When a cache entry is evicted, the corresponding slot is returned to the free slot list to wait for reuse.

[0030] Specifically, the free slot linked list adopts a singly linked list structure, with the head pointer pointing to the first free slot, and each free slot storing the index of the next free slot. When allocating a slot, the slot pointed to by the head pointer is retrieved, and the head pointer is updated to the index of the next free slot; the operation has a constant time complexity. When reclaiming a slot, the slot to be reclaimed is inserted into the head of the linked list, and the head pointer is updated to point to that slot; this operation also has a constant time complexity. Using a free slot linked list management method avoids frequent memory allocation and deallocation operations. All slots are allocated all at once during initialization, and reuse occurs only through the linked list during runtime, significantly reducing memory management overhead and adapting to the high-performance requirements of kernel mode.

[0031] Specifically, the process of mounting scheduling event hooks involves attaching the eBPF program to a stable tracepoint node in the kernel scheduling subsystem. A tracepoint is a predefined static hook point in the kernel, located at a fixed position within a kernel function. It possesses good version compatibility and stability and is not easily changed with minor kernel version upgrades. Scheduling-related tracepoint nodes are distributed across various critical paths in the scheduling subsystem, including process wake-up, process switching, wait statistics, and process migration. Each tracepoint, when triggered, carries corresponding event parameters, including process identifier, event timestamp, and event cause information, which can be directly used for statistical calculations. The tracepoint nodes selected in this application are all stable nodes that have been supported by the kernel mainline for a long time, compatible with mainstream kernel versions, and can be directly deployed on cloud platform host machines of different versions without requiring extensive adaptation work for different kernel versions.

[0032] Specifically, the process of attaching the scheduling tick hook involves attaching the eBPF program to the tracepoint node or function entry point corresponding to the scheduling tick interrupt of each physical CPU. The scheduling tick interrupt is triggered by the kernel clock interrupt, and each physical CPU triggers it independently according to its configured frequency, typically several hundred hertz, corresponding to a millisecond-level trigger interval. The main functions of the scheduling tick interrupt include updating the time slice of the currently running process, updating CPU load statistics, and triggering the scheduler's load balancing check, making it an inherent component of the kernel scheduling system. This application attaches the hotspot ranking update logic to the execution path of the scheduling tick interrupt, which is equivalent to performing additional statistical maintenance operations on top of the original kernel logic. It does not change the original kernel scheduling tick function or execution frequency, nor does it add any interrupt sources or timers, thus avoiding additional triggering overhead. Simultaneously, each CPU's tick interrupt handles its own local cache, naturally adapting to a per-CPU cache architecture, eliminating the need for cross-CPU data interaction, resulting in simple logic and high execution efficiency.

[0033] In the embodiments of this application, such as Figure 2 As shown, in response to a scheduling event, the corresponding vCPU's statistical increment is updated first in the local cache of the current physical CPU. If the local cache is not hit, the global hash mapping is updated. In response to a scheduling Tick interrupt, the vCPU popularity ranking in the local cache is updated and the cache entries are adjusted, including: S201: Parse the vCPU identifier and metric increment corresponding to the scheduling event, and match the local cache entry of the current physical CPU; S202: When a cache entry is hit, the increment of the metric is accumulated in the local cache; when a cache entry is not hit, the corresponding statistical value of the global hash map is updated and the heat count of the corresponding vCPU is accumulated. S203: In response to a scheduling Tick interrupt, update the heat value of each vCPU based on a sliding window and adjust the cache entries in the local cache.

[0034] Specifically, parsing scheduling event information is the first step in the execution of the scheduling event hook, used to obtain the basic data required for statistical updates. When a scheduling event is triggered, the kernel passes the context parameters corresponding to the event to the eBPF hook program. The parameters include the process identifier that triggered the event, the timestamp of the event occurrence, the event type, and event-related auxiliary parameters. The hook program first extracts the vCPU thread identifier corresponding to the current event from the parameters. The thread identifier can uniquely identify the corresponding vCPU. Then, it determines the statistical item corresponding to this event based on the event type and calculates the metric increment generated by this event. Different types of events correspond to different statistical item calculation logics. For example, the waiting statistics event corresponds to the statistics of ready waiting time. The event parameters directly carry the ready waiting time, which can be directly used as the metric increment. The context switch event corresponds to the statistics of scheduling runtime and preemption time. When a process is switched out, the switchout time and switchout reason are recorded. If the switchout reason is preemption, the preemption start time is recorded. When the process is scheduled back in, the preemption time is calculated as the metric increment, and the runtime of this scheduling is also calculated as the runtime increment. The statistics of blocking events correspond to the blocking wait time. When a process enters a blocked state, the blocking start time is recorded. When the process is awakened, the blocking time is calculated as the indicator increment.

[0035] Specifically, matching local cache entries is a crucial step in the hot path, determining whether a fast update can be achieved through the local cache. The matching operation uses the vCPU's thread identifier as the matching key, traversing all valid hot entries in the current CPU's local cache, comparing the thread identifier stored in each entry with the thread identifier of the current event. If a matching entry is found, it's considered a cache hit; otherwise, it's considered a cache miss. Since the number of entries in the local cache is relatively small, typically in the tens, the total overhead of sequential traversal is very low, far lower than the overhead of hash calculations and global memory access. Therefore, sequential traversal will not become a performance bottleneck; on the contrary, it can eliminate the hash calculation step, further compressing the execution length of the hot path. The matching process only performs identifier comparison and does not involve complex calculations, resulting in fast execution speed, consistent with the principle of minimalist hot path design.

[0036] Specifically, the update logic upon a cache hit is very simple: the increment of the calculated metric is directly added to the corresponding statistical item of the local cache entry. Since the local cache is private to the current CPU and there are no concurrent write conflicts, atomic operations are unnecessary; a simple memory addition instruction suffices for the accumulation, resulting in extremely low execution overhead. After the update, the main logic of the scheduling event hook is complete, and it can exit directly. The entire process involves only local memory access, without accessing global memory or any concurrency protection operations, minimizing the impact on native scheduling. The higher the proportion of cache hits among all scheduling events, the more significant the overall performance improvement. In typical virtualization load scenarios, a small number of high-load vCPUs contribute most of the scheduling events, thus maintaining a high cache hit rate and resulting in significant overall performance gains.

[0037] Specifically, when a cache miss occurs, the global hash map needs to be accessed to update the statistics. When accessing the global hash map, the read-side critical section of the read-copy update is entered to find the hash node for the corresponding vCPU. Once the node is found, an atomic accumulation operation is used to update the metric increment to the corresponding statistical item of the node. Since multiple CPUs may update the same vCPU's statistical item simultaneously, an atomic accumulation operation is needed to ensure data correctness and avoid data overwriting errors caused by concurrent writes from multiple CPUs. The granularity of the atomic operation is only a single statistical item, much smaller than the granularity of a global lock, resulting in significantly lower overhead. After updating the statistical value, the heat count for the corresponding vCPU also needs to be accumulated once to record that the vCPU has been accessed once on the current CPU, for use in subsequent hotspot ranking calculations. The heat count can be stored in a local heat statistics structure or in a global hash node. In this embodiment, the heat count is stored locally and is only used for hotspot ranking calculations for the current CPU. Different CPUs independently maintain their own heat statistics, eliminating the need for cross-CPU synchronization and further reducing overhead.

[0038] Specifically, when a scheduling tick interrupt is triggered, the logic for hotspot updates and cache adjustments is executed. This logic runs within the tick interrupt context and is not part of the hot path of the scheduling event; therefore, it can perform relatively complex calculations without affecting the latency of the native scheduling. Hotspot updates are implemented using a sliding window mechanism, which counts the access frequency of each vCPU over the most recent tick cycles as the basis for calculating the heat value. The sliding window mechanism can smooth out the impact of instantaneous access fluctuations, avoiding drastic changes in hotspot rankings caused by a single sudden access, and reducing the overhead of frequent cache entry replacements. Based on the updated heat value, the entries in the local cache are sorted, the lowest-heat entries are evicted, and external vCPUs that meet the heat admission criteria are added to the cache, completing the dynamic adjustment of cache entries. The frequency of cache adjustments is consistent with the tick frequency, at the millisecond level, which can promptly follow load changes and ensure that the cache hit rate remains at a high level.

[0039] In the embodiments of this application, such as Figure 6 As shown, the vCPU identifier and metric increment corresponding to the parsed scheduling event are matched with the local cache entries of the current physical CPU, including: S601: Extract the vCPU thread identifier and event type from the context information of the scheduling event, and calculate the metric increment corresponding to this event; S602: Traverse the hot entry storage area of ​​the local cache using the vCPU's thread identifier as the matching key; S603: Compare the consistency of thread identifiers to determine the cache hit status.

[0040] Specifically, the process of extracting vCPU thread identifiers and event types depends on the parameters carried by the tracepoint event. Different types of scheduling events carry different parameter structures, but all include information related to the process that triggered the event. For process switching events, the parameters include the process identifiers of the process that switched out and the process that switched in. The two processes correspond to different statistical update logics: the process that switched out needs to have its runtime or preemption start time recorded, while the process that switched in needs to have its waiting end time or preemption end time recorded. For waiting statistics events, the parameters include the process identifier of the corresponding process and the waiting duration, directly corresponding to the ready waiting statistics item. For process wake-up events, the parameters include the process identifier of the woken-up process and the wake-up reason, used to distinguish different types of wake-ups and corresponding to different statistical logics. In this application, the kernel thread identifier is uniformly used as the unique identifier for the vCPU. The thread identifier is a unique number used by the kernel scheduler to manage threads; each thread corresponds to a unique number, and they will not be repeated.

[0041] Specifically, the logic for calculating metric increments varies depending on the event type. All calculations are based on the timestamp carried by the event or the directly provided duration parameter. For events that directly carry duration parameters, such as waiting statistics events, the duration parameter can be directly used as the increment of the corresponding statistical item without additional calculation. For events that require calculating duration through timestamp differences, such as preemption duration, runtime, and blocking duration, the start timestamp of the corresponding state needs to be recorded. When the state ends, the current timestamp is subtracted from the start timestamp to obtain the duration of the corresponding state, which is used as the metric increment. The start timestamp can be stored in the corresponding entry in the local cache or in the global hash node. In this embodiment, the start timestamp of the state class is stored in the global hash node to ensure that the start time can still be read normally after vCPU cross-core migration, avoiding calculation errors caused by state interruption. The timestamp uses the kernel's native scheduling clock with nanosecond precision, which can accurately count the duration of scheduling events at the microsecond level, meeting the needs of fine-grained monitoring.

[0042] Specifically, the process of traversing the local cache hot item storage area involves accessing valid items sequentially. The local cache hot item storage area uses an array structure, with each slot corresponding to an array element containing fields such as a validity flag, vCPU thread identifier, various statistical increments, and popularity value. The validity flag indicates whether the slot stores a valid hot item; a true flag means the slot is in use, while a false flag indicates the slot is idle and falls under the management scope of the idle slot list. During traversal, only items with a true validity flag are checked, skipping idle slots to reduce the number of traversals. The traversal terminates when all slots have been traversed or a matching item is found. Since the number of cached items is limited, the total number of traversals is controllable, and the worst-case traversal overhead is far lower than the overhead of global memory access, thus not significantly impacting hot path performance.

[0043] Specifically, the process of comparing thread identifier consistency directly compares the vCPU thread identifier of the current event with the thread identifier stored in the entry. If the two values ​​are exactly equal, it is considered a match; otherwise, it is considered a mismatch. The thread identifier is an integer value, and the value comparison is a single-instruction operation, which is extremely fast and does not incur additional overhead. After finding a matching entry, the index position of the entry is recorded for subsequent incremental update operations, and the traversal process is terminated to reduce unnecessary calculations. If no matching item is found after traversing all valid entries, it is considered a cache miss, and the process then proceeds to global hash access. The entire matching process has simple logic and a short execution path, meeting the requirements of a minimalist hot path design, ensuring that the scheduling event hook can be executed quickly and return to the original kernel scheduling process as soon as possible.

[0044] In the embodiments of this application, such as Figure 5As shown, the step of responding to a scheduling Tick interrupt by updating the heat value of each vCPU based on a sliding window and adjusting the cache entries in the local cache includes: S501: Count the access records of each vCPU in the current Tick cycle and update the heat count value in the sliding window; S502: Remove cache entries with a popularity value lower than the eviction threshold from the storage area and add the corresponding slot to the free slot linked list; S503: Allocate free slots to non-cached vCPUs whose heat values ​​reach the admission threshold and add them to the local cache storage area.

[0045] Specifically, the sliding window is implemented using a fixed-length circular array. Each element of the array corresponds to the access statistics for one tick cycle, and the array length corresponds to the total length of the sliding window. At the start of each tick cycle, the window pointer moves forward one position to the oldest window position, clears the old statistics at that position, and then writes the new statistics for the current tick cycle, thus achieving the sliding effect. This circular array implementation eliminates the need for frequent memory allocation and deallocation; window sliding is completed simply by pointer movement and value updates, resulting in extremely low execution overhead and making it suitable for operation in interrupt contexts. The sliding window length is configurable. A longer length results in smoother access values ​​and more stable cache entries, but lower sensitivity to hotspot changes. A shorter length makes the access values ​​more sensitive to changes and allows for faster hotspot switching, but it is more susceptible to instantaneous fluctuations that can cause cache thrashing. In actual deployment, the appropriate window length can be selected based on the load characteristics of the business scenario. Longer windows are suitable for scenarios with stable loads, while shorter windows are suitable for scenarios with large load fluctuations.

[0046] Specifically, the heat count is the sum of access counts across all periods within the sliding window, representing the total access frequency of that vCPU in a recent period. Each tick update of the window subtracts the old access counts from those removed from the window and adds the new access counts for the current period to obtain the latest total heat value. This eliminates the need to re-accumulate data for all windows, resulting in high computational efficiency. Heat counts are calculated independently per vCPU, with each vCPU corresponding to a total heat value. A higher value indicates a higher recent access frequency for that vCPU, making it more eligible for local caching. Heat statistics only count access counts and do not distinguish between event types. This is because any access incurs global hashing overhead, regardless of event type; counting by count ensures comprehensive coverage for cache optimization.

[0047] Specifically, the process of evicting cached entries first iterates through all valid entries in the local cache, compares the popularity values ​​of each entry, and identifies entries with popularity values ​​below the eviction threshold. The eviction threshold is a preset value that can be configured according to scenario requirements, typically set to a low value to ensure that entries that have not been accessed for a long time or have extremely low access frequency can be evicted promptly, freeing up cache slots. Alternatively, a bottom-ranking eviction approach can be used, evicting the last few entries in each iteration to ensure that the most popular vCPUs are always retained in the cache. This method does not require setting a fixed threshold and automatically adapts to the overall access level, avoiding the simultaneous eviction or admission of a large number of entries when the overall load increases or decreases. After finding the entries to be evicted, the remaining statistical increments in the entries are first synchronized to the global hash map to prevent data loss. Then, the valid flag of the entry is set to invalid, and the corresponding slot is added to the free slot linked list, completing the eviction process. Incremental synchronization can be performed immediately during eviction or wait for a unified synchronization cycle. In this embodiment, incremental synchronization is performed during eviction to ensure that data is synchronized globally in a timely manner, preventing the reuse of slots after eviction and the loss of incremental data.

[0048] Specifically, the process of admitting new hot entries first involves calculating the popularity of all vCPUs not yet in the cache and identifying those whose popularity reaches the admission threshold. The admission threshold is typically higher than the eviction threshold, creating a certain hysteresis range to prevent vCPUs from repeatedly entering and exiting the cache when their popularity fluctuates around the threshold, thus reducing cache jitter. When a vCPU meets the admission criteria and there are available slots in the free slot list, a slot is retrieved from the free list, filled with the vCPU's thread identifier, the initial statistical increment is set to zero, and the valid flag is set to true, completing the admission operation. If the number of eligible vCPUs exceeds the number of free slots, they are admitted sequentially from highest to lowest popularity until all slots are used. If there are insufficient free slots and there are already cached entries with lower popularity than the vCPUs to be admitted, the lowest-popularity entries can be evicted, freeing up slots for higher-popularity vCPUs, ensuring that the entries in the cache are always the most currently popular. This balance between eviction and admission ensures cache utilization, always covering the maximum number of access requests with limited slots, maintaining a high cache hit rate.

[0049] In the embodiments of this application, such as Figure 9 As shown, the method further includes: S901: Collect the scheduling event density within the unit window and adjust the step size of the sliding window according to the scheduling event density; S902: When the scheduling event density increases, shorten the sliding window step size; when the scheduling event density decreases, lengthen the sliding window step size.

[0050] Specifically, scheduling event density refers to the total number of scheduling events triggered on the current physical CPU per unit time, reflecting the current scheduling activity level of the CPU. Scheduling event density can be obtained by counting the number of scheduling events within each tick cycle. At the end of each tick cycle, the total number of events triggered within that cycle is counted as the basis for density calculation. A smoothed event density can be calculated using a moving average method to avoid frequent adjustments to the step size due to sudden fluctuations in a single cycle. Higher scheduling event density indicates more frequent scheduling, potentially faster changes in vCPU load, and faster hotspot switching. In this case, a more sensitive hotspot update mechanism is needed to promptly identify new hotspots and add them to the cache, preventing a decrease in hit rate. Lower scheduling event density indicates sparser scheduling, relatively stable vCPU load, and slower hotspot switching. In this case, the sensitivity of hotspot updates can be reduced to minimize the overhead of frequent cache entry replacements.

[0051] Specifically, the sliding window step size refers to the distance the window slides with each tick. A shorter step size results in faster data updates and more sensitive heat values; a longer step size results in slower data updates and smoother heat values. Step size adjustment is implemented using a tiered approach, setting multiple density intervals, each corresponding to a step size value. When the event density rises to the upper threshold of the corresponding interval, a shorter step size is used; when the event density falls to the lower threshold, a longer step size is used. A certain difference is set between the upper and lower thresholds to form a hysteresis interval, preventing frequent step size switching when density fluctuates around the threshold, which could lead to system instability. The step size adjustment logic is executed in the tick interrupt, running alongside the hotspot update logic. No additional triggering mechanism is required, making it simple and low-overhead. By dynamically adjusting the step size, good caching performance can be achieved under different load scenarios, balancing sensitivity under high load and stability under low load, thus improving the solution's scenario adaptability.

[0052] In the embodiments of this application, such as Figure 8 As shown, the method further includes: S801: In response to the vCPU cross-core migration event, synchronize the statistical increment of the corresponding vCPU in the local cache of the migrated physical CPU to the global hash map; S802: Mark the cache entry of the corresponding vCPU in the physical CPU to be evicted; S803: The migrated physical CPU accumulates the heat count of the corresponding vCPU in subsequent scheduling events, and is added to the local cache after reaching the admission threshold.

[0053] Specifically, vCPU cross-core migration is a common phenomenon in virtualization scenarios. The Linux kernel's Completely Fair Scheduler automatically migrates processes from high-load CPUs to low-load CPUs based on their load, achieving load balancing. vCPUs, as ordinary kernel threads, also participate in load balancing scheduling and therefore migrate between different physical CPUs. After a vCPU migration, its subsequent scheduling events are triggered on the new CPU; no scheduling events for that vCPU will be generated on the original CPU. Without special handling, the vCPU's entry in the original CPU's local cache will continuously occupy slots, and its statistical increments cannot be synchronized globally in a timely manner, leading to data convergence delays and wasted cache slots. This application addresses this by attaching hooks to process migration events, enabling real-time detection and targeted handling of vCPU cross-core migration events, thus resolving data consistency and cache utilization issues caused by migration.

[0054] Specifically, when a vCPU cross-core migration event is detected, the outgoing CPU number, the incoming CPU number, and the corresponding vCPU's thread identifier are first obtained. For the outgoing CPU, the local cache is checked to see if an entry for that vCPU exists. If it exists, the statistical increment in the entry is synchronized to the global hash map to ensure no data loss. After synchronization, the entry is marked as pending eviction. During the next hotspot ranking update, this entry will be evicted because its popularity will no longer increase, and the corresponding slot will be reclaimed to the free list for other vCPUs to use. For the incoming CPU, this vCPU is a newly arrived thread and is initially not in the incoming CPU's local cache. Subsequent scheduling events will first access the global hash map and accumulate the vCPU's popularity count. When the popularity count reaches the admission threshold, the vCPU will be added to the incoming CPU's local cache, and subsequent scheduling events can be quickly updated through the local cache.

[0055] Specifically, the migration processing logic ensures that data is not lost after vCPUs migrate across cores, cache slots are released promptly, and data is gradually incorporated into the hotspot cache on the new CPU. The entire process is automated and requires no manual intervention. Migration event hooks are also attached to stable tracepoint nodes in the kernel. When an event is triggered, the corresponding processing logic is executed with very low overhead and has no significant impact on the migration process. By specifically addressing migration scenarios, the solution improves stability and data accuracy in dynamic scheduling environments and adapts to the dynamic load balancing characteristics of cloud platforms.

[0056] In the embodiments of this application, such as Figure 4 As shown, the step of synchronizing the statistical increment of the local cache to the global hash map, and generating vCPU scheduling contention monitoring data based on the statistical data of the global hash map, includes: S401: At the end of the read copy update grace period, the statistical increment of each physical CPU's local cache is accumulated into the corresponding entry of the global hash map; S402: Clear the statistical increment in the local cache, and retain the value of the popularity count field; S403: Read the statistical data of the global hash mapping and generate vCPU scheduling contention monitoring data by combining the mapping relationship between virtual machine identifier and vCPU identifier.

[0057] Specifically, the statistical increments of the local cache need to be periodically synchronized to the global hash map to ensure the integrity of global data and provide complete statistical data for user-space reads. Synchronization is chosen to occur at the end of the read-copy update grace period because by this time all CPUs have exited the critical section that might access the old hash node. Writing operations at this point will not conflict with read operations, and read operations do not need to be blocked, which aligns with the design principles of read-copy updates. The grace period can be automatically triggered by the kernel's read-copy update mechanism or actively triggered at fixed time intervals. The synchronization frequency does not need to be too high, as long as it is completed before user-space reads. Typically, a synchronization frequency of tens of hertz is sufficient, far exceeding the second-level read frequency of user-space, which is perfectly adequate to guarantee data convergence.

[0058] In the embodiments of this application, such as Figure 7 As shown, the step of accumulating the statistical increment of each physical CPU's local cache into the corresponding entry of the global hash map at the end of the read copy update grace period includes: S701: Detect the grace period status of the read copy update mechanism and confirm that all read-side critical sections have exited; S702: Traverse all hot entries in the local cache of each physical CPU and extract the corresponding statistical increments; S703: Writes the statistical increment to the corresponding vCPU entry of the global hash map through an atomic accumulation operation.

[0059] Specifically, the process of detecting the grace period status can be accomplished through read-copy-update related helper functions provided by the kernel. A corresponding callback will be triggered when the grace period ends, or the synchronization function can be actively called to wait for the grace period to complete. This embodiment uses periodic synchronization, triggering synchronization every fixed number of ticks. During synchronization, read-copy-update synchronization is performed first, and incremental writes are performed after the grace period ends. Active synchronization allows for better control of the synchronization frequency, adapting to different scenario requirements. For scenarios with high real-time synchronization requirements, the synchronization frequency can be increased, while for scenarios with high performance requirements, the synchronization frequency can be decreased.

[0060] Specifically, the process of traversing hot entries in the local cache involves reading the incremental values ​​of each statistical item for each valid entry, preparing them for writing to the global map. This traversal process is executed independently on each CPU, processing its own local cache without cross-CPU interaction. After extracting the incremental value, the corresponding vCPU node in the global hash map needs to be found, and then an atomic accumulation operation is performed. If the corresponding vCPU node does not exist in the global hash, it indicates a newly created vCPU. In this case, a hash node needs to be added first, initializing the statistical value to the current incremental value. The operation of adding a node follows a read-copy-update write process: a new node is created first, and then atomically inserted into the hash list, ensuring the safety of read operations.

[0061] Specifically, atomic accumulation operations are performed on individual statistical items, with each item accumulated independently using the atomic addition instructions provided by the kernel. Atomic operations ensure that when multiple CPUs simultaneously perform addition on the same memory address, no overwrite error occurs, and the increments from all CPUs are correctly accumulated. Since the frequency of synchronization operations is far lower than the frequency of scheduling events, the total overhead of atomic operations is very low and will not become a performance bottleneck. After synchronization is complete, the statistical increment field in the local cache is cleared to zero, and the next statistical cycle begins. The value of the popularity count field is retained and continues to be used for subsequent hotspot ranking statistics; it does not need to be cleared because popularity is continuously counted via a sliding window and is independent of the synchronization cycle.

[0062] Specifically, the operation of reading global hash mapping statistics is performed by the user-space resolution service. User-space programs read all entries in the kernel-space global hash mapping through the user-space interface provided by eBPF. The read operation is performed at a fixed statistical period, typically on the order of seconds, which can be adjusted according to the real-time requirements of monitoring. After reading the statistics for all vCPUs, the statistics for all vCPUs corresponding to the same virtual machine are aggregated using a pre-maintained mapping table of virtual machine identifiers and vCPU identifiers to obtain the total statistics for the virtual machine dimension. The mapping table is established when the virtual machine is created, recording the thread identifiers of all vCPUs corresponding to each virtual machine. The mapping relationship is deleted when the virtual machine is destroyed to ensure the accuracy of the mapping relationship.

[0063] Specifically, the process of generating vCPU scheduling contention monitoring data involves calculating various contention metrics based on aggregated statistical data. The ready contention rate is the ratio of total ready waiting time to the total duration of the statistical period, reflecting the degree of queuing contention for vCPU scheduling. The kernel preemption loss rate is the ratio of total kernel preemption time to the total duration of the statistical period, reflecting the degree of preemption interference of system kernel scheduling on vCPU operation. The scheduling loss time rate is the ratio of the sum of ready waiting time and kernel preemption time to the total duration of the statistical period, reflecting the percentage of time vCPUs cannot operate normally. The overall contention score is a weighted average of multiple metrics, used to comprehensively assess the severity of vCPU resource contention. These calculated metrics, along with corresponding virtual machine identifiers, vCPU identifiers, and statistical periods, together constitute the vCPU scheduling contention monitoring data. This data can be output to a monitoring platform for display or input into an alarm system. When a metric exceeds a threshold, an alarm is triggered to notify operations personnel. It can also serve as input data for cloud platform resource scheduling, supporting optimization operations such as load migration, resource expansion, and scheduling weight adjustment.

[0064] In this embodiment, the eBPF-based virtual machine vCPU scheduling contention monitoring device includes a storage construction module, an event processing module, and a data generation module. The storage construction module is used to construct a global hash map protected by a read-copy-update mechanism and the local cache corresponding to each physical CPU, and to attach scheduling event hooks and scheduling tick hooks. The event processing module, in response to a scheduling event, prioritizes updating the statistical increment of the corresponding vCPU in the local cache of the current physical CPU; if the local cache is not hit, it updates the global hash map; and in response to a scheduling tick interrupt, it updates the vCPU popularity ranking in the local cache and adjusts the cache entries. The data generation module is used to synchronize the statistical increment of the local cache to the global hash map and generate vCPU scheduling contention monitoring data based on the statistical data of the global hash map.

[0065] Specifically, the storage building module runs during the eBPF program's initialization phase, completing the creation of all storage structures and the mounting of hooks during program loading. The storage building module is responsible for configuring various parameters of the global hash mapping, including key length, value length, maximum number of entries, and concurrency protection methods, ensuring that the global mapping meets the needs of the business scale. The storage building module is also responsible for allocating local cache memory space for each physical CPU, initializing the various components of the local cache, and setting initial cache parameters, including eviction threshold, admission threshold, and sliding window length. Furthermore, the storage building module is responsible for mounting all eBPF hooks, including scheduling event hooks, scheduling tick hooks, and process migration hooks, ensuring that all necessary events are correctly captured.

[0066] Specifically, the event processing module is the main operating module of the device, running in kernel mode. It is responsible for handling various triggered events and completing statistical updates and cache maintenance. The event processing module consists of two parts: a scheduling event processing unit and a Tick event processing unit. The scheduling event processing unit corresponds to the execution logic of the scheduling event hook, and is responsible for parsing event information, matching local cache, and performing statistical updates and heat counting. The Tick event processing unit corresponds to the execution logic of the scheduling Tick hook, and is responsible for updating the sliding window heat, adjusting cache entries, and performing dynamic step size adjustments. The event processing module also includes a migration event processing unit, which corresponds to the execution logic of the process migration hook, and is responsible for handling cache synchronization and marking operations in vCPU cross-core migration scenarios. The three units cooperate with each other to complete all statistical and cache maintenance work in kernel mode.

[0067] Specifically, the data generation module is divided into two parts: a kernel-mode synchronization unit and a user-mode parsing unit. The kernel-mode synchronization unit is responsible for performing the synchronization operation of local cache incremental to global hash mapping, ensuring the convergence of global data. The user-mode parsing unit is responsible for reading global statistical data, associating it with virtual machine identifiers, calculating multi-dimensional contention indicators, and generating the final monitoring data. The data generation module connects kernel-mode data collection with upper-layer business applications, transforming the raw statistical data from the kernel mode into monitoring indicators usable by the business, supporting subsequent business operations such as alarms, scheduling, and optimization.

[0068] For example, the implementation process of this application is described below in conjunction with a specific operating scenario. A cloud platform host machine is equipped with a multi-core physical CPU, running a Linux operating system and a KVM virtualization environment, hosting multiple virtual machines, each virtual machine configured with several vCPUs. The monitoring device of this application is deployed on the host machine. When the eBPF program is loaded, the storage construction module creates a global hash mapping, uses a read-copy-update mechanism for protection, allocates a fixed-length local cache to each physical CPU, initializes the hot entry storage area, the heat count field, and the free slot linked list, and then attaches the scheduling event hook, the scheduling Tick hook, and the process migration hook to complete the initialization deployment.

[0069] During operation, a virtual machine's vCPU, running on a physical CPU, is preempted by another process, triggering a scheduling switch event and initiating a scheduling event hook. The hook program extracts the vCPU's thread identifier and event type, calculates the metric increment corresponding to this preemption, and then iterates through the local cache entries of the current physical CPU. This vCPU is a high-load business vCPU, consistently in a high-access-frequency state, therefore a corresponding entry exists in the local cache, resulting in a cache hit. The hook directly increments the preemption duration in the local cache entry, exits after completion, and returns to the kernel's original scheduling flow. The entire process only accesses local memory, resulting in fast execution and no significant impact on scheduling latency.

[0070] When another low-load vCPU triggers a scheduling event, the hook program searches the local cache but finds no corresponding entry, resulting in a cache miss. The hook then enters the global hash access process, finds the corresponding node in the global hash map, accumulates the metric increment through atomic operations, and simultaneously increments the heat count of the corresponding vCPU. After completion, the hook exits. The heat count of this vCPU gradually accumulates with the number of accesses. When the heat value reaches the admission threshold and there are free slots in the cache, it will be included in the local cache during the next Tick update, allowing subsequent accesses to quickly hit the cache and process them.

[0071] When each scheduling tick interrupt is triggered, the tick event processing unit updates the heat data of the sliding window, recalculates the heat value of each vCPU, evicts entries with heat values ​​below the threshold, reclaims the corresponding slots, and admits new hot entries that meet the conditions. When the host machine's service load increases and the scheduling event density increases, the sliding window automatically shortens its step size to improve the sensitivity of hotspot updates and keep up with load changes in a timely manner. When the load decreases, the sliding window automatically lengthens its step size to maintain cache stability.

[0072] When a vCPU migrates from one physical CPU to another due to load balancing, a migration event hook is triggered. The migrating CPU synchronizes the incremental value of the corresponding cache entry to the global hash, marking the entry as pending eviction. This entry will be evicted and reclaimed during subsequent tick updates. The scheduling events of the vCPU on the migrating CPU gradually accumulate heat, and once a threshold is reached, they are added to the local cache of the migrating CPU. The entire process is completed automatically, without data loss, and cache resources can be effectively reused.

[0073] When the fixed synchronization period arrives, the kernel-mode synchronization unit performs a synchronization operation. After the read-copy update grace period ends, it atomically accumulates the statistical increments of each CPU's local cache into the global hash map, then clears the local increment field and enters the next statistical period. The user-mode parsing unit reads the full data of the global hash every second, combines it with the virtual machine identifier mapping table, aggregates and calculates the contention indicators of each virtual machine, generates vCPU scheduling contention monitoring data, and outputs it to the monitoring platform and alarm system to support subsequent operation and maintenance and optimization operations.

[0074] It should be noted that existing similar scheduling and statistics implementations typically employ a globally unified storage architecture, where all scheduling events directly access the global statistics structure. Some optimization schemes address concurrency protection at the granular level, such as reducing lock contention by bucketing the global hash or using lighter-weight concurrency protection mechanisms. Conventional cache optimization approaches tend to localize all data to achieve the highest access performance. This approach is common in user-space programs but is difficult to implement directly in kernel-space eBPF scenarios due to memory quota limitations. For cache maintenance logic, conventional implementations often use independent timed components to trigger updates or update the cache on each access. The former increases system resource consumption, while the latter increases the computational overhead of the access path. This application adopts a fixed-length hotspot filtering two-level storage architecture, only sinking the most frequently accessed data to the local storage. This achieves the localization of most accesses within the limited kernel memory, while reusing the kernel's native periodic interrupts as the trigger for cache maintenance. This eliminates the need for an independent timed component, and the maintenance logic is separated from the execution path of scheduling events, thus avoiding increased computational load on the scheduling hot path. This type of design combines the access distribution characteristics of virtualization scheduling scenarios with the native mechanisms of kernel operation, which is significantly different from conventional optimization paths.

[0075] Furthermore, all mechanisms in this application are implemented based on the kernel's native eBPF capabilities and scheduling mechanisms, requiring no modification to the kernel source code or loading of additional kernel modules. Deployment is simple, with strong compatibility, and it can be directly applied to mainstream cloud platform host environments. All parameters of the solution are configurable, allowing adjustment of parameters such as cache size, threshold, and window length according to different business scenarios and hardware environments to achieve suitable operational results. The solution design follows the principle of minimalist kernel-mode programs, simplifying hot path logic as much as possible and moving complex logic to asynchronous paths or user space for execution, minimizing the performance impact of monitoring on business systems and meeting the low-intrusion design goal of virtualization monitoring.

[0076] In existing implementations of similar technology, optimizations to scheduling statistics performance are mostly focused on concurrency optimization of global storage, with less emphasis on building a secondary storage architecture based on access locality characteristics, and less consideration given to reusing native kernel functions to absorb cache maintenance overhead. This application, through a combination of multi-layered technical designs, effectively improves scheduling statistics performance under multiple constraints of memory, performance, and deployment, adapting to the needs of high-density virtualization deployments on cloud platforms.

[0077] Specifically, the two-level storage architecture, rather than a full per-CPU statistics design, is adopted because full per-CPU statistics require reserving statistical space for each vCPU on each CPU. When the number of vCPUs is large, the total memory consumption becomes very large, far exceeding the eBPF memory quota. In contrast, the fixed-length hotspot caching approach stores only a small number of hotspot entries per CPU, keeping the total memory consumption controllable and covering most accesses, achieving better performance gains under memory constraints. Full per-CPU statistics also incur significant overhead for user-space aggregation, requiring the user space to traverse all vCPU entries across all CPUs to obtain global data. When the number of vCPUs is large, the aggregation overhead is extremely high. The two-level architecture in this application completes incremental synchronization in kernel space, allowing user space to directly read global data without performing extensive aggregation calculations, thus reducing user-space processing overhead.

[0078] Specifically, atomic operations offer finer granularity and lower overhead compared to spinlocks. Spinlocks require protection of the entire critical section, with all operations within that section under lock protection. This can lead to busy waiting during multi-core contention, consuming significant CPU resources. In contrast, atomic operations execute on a single memory variable, ensuring atomicity at the hardware level and eliminating the need for software-level locks, resulting in significantly lower overhead than spinlocks. In this application, the global hash statistical update uses atomic operations, protecting only a single variable with extremely fine granularity. The probability and overhead of multi-core conflicts are far lower than with spinlock schemes. Combined with read-copy update to protect the hash structure, the overall concurrency performance surpasses traditional global spinlock schemes.

[0079] Specifically, the design of storing only incremental values ​​in the local cache can also reduce data risks during synchronization. If the full value is stored, synchronization requires overwriting the global data with the full value. When multiple CPUs simultaneously overwrite the same variable, data loss can occur, necessitating locking protection, which incurs significant overhead. However, when storing incremental values, synchronization only requires an atomic accumulation operation. Increments from multiple CPUs can be accumulated simultaneously without overwriting each other, eliminating the need for lock protection. Atomic instructions alone guarantee correctness, resulting in simpler logic and better performance. Furthermore, the accumulation of incremental values ​​is idempotent. Even if duplicate synchronization occurs, a verification mechanism can identify it, preventing data errors and improving the system's fault tolerance.

[0080] For example, in actual deployment, parameters such as the number of local cache slots, sliding window length, eviction and admission thresholds can be flexibly adjusted based on the virtual machine scale and load characteristics of the host machine. For scenarios with concentrated business load and a small number of hot vCPUs, the number of cache slots can be appropriately reduced to further reduce memory consumption; for scenarios with dispersed business and a large number of hot vCPUs, the number of cache slots can be appropriately increased to improve cache hit rate. This flexible parameter configuration capability allows the solution to adapt to different types of cloud platform business scenarios, achieving the desired operational performance for each scenario.

Claims

1. A virtual machine vCPU scheduling contention monitoring method based on eBPF, characterized in that, include: A global hash map protected by a read-copy-update mechanism and the local cache corresponding to each physical CPU are constructed, and scheduling event hooks and scheduling Tick hooks are attached. The read-copy-update mechanism provides a synchronization mechanism for the kernel to protect concurrent access. In response to a scheduling event, the statistical increment of the corresponding vCPU is updated in the local cache of the current physical CPU first. If the local cache is not hit, the global hash mapping is updated. In response to a scheduling Tick interrupt, the vCPU popularity ranking in the local cache is updated and the cache entries are adjusted. The statistical increments of the local cache are synchronized to the global hash map, and vCPU scheduling contention monitoring data are generated based on the statistical data of the global hash map.

2. The virtual machine vCPU scheduling contention monitoring method based on eBPF according to claim 1, characterized in that, In response to a scheduling event, the system first updates the statistical increment of the corresponding vCPU in the local cache of the current physical CPU. If the local cache is not hit, the global hash mapping is updated. In response to a scheduling tick interrupt, the system updates the vCPU popularity ranking in the local cache and adjusts the cache entries, including: Parse the vCPU identifier and metric increment corresponding to the scheduling event, and match it with the local cache entry of the current physical CPU; When a cache entry is hit, the increment of the aforementioned metric is accumulated in the local cache; when a cache entry is missed, the corresponding statistical value of the global hash map is updated and the heat count of the corresponding vCPU is accumulated. In response to a scheduling Tick interrupt, the heat value of each vCPU is updated based on a sliding window, and the cache entries in the local cache are adjusted.

3. The virtual machine vCPU scheduling contention monitoring method based on eBPF according to claim 1, characterized in that, The construction of the global hash map protected by the read-copy-update mechanism and the local cache corresponding to each physical CPU, and the attachment of scheduling event hooks and scheduling tick hooks, include: Create a global hash map and use a read-copy-update mechanism to protect the global hash map from concurrent access. A fixed-length local cache is allocated to each physical CPU. The local cache includes a hot entry storage area, a hotness count field, and a free slot linked list. Mount scheduling event hooks to kernel scheduling tracepoint nodes and schedule tick hooks to scheduling tick interrupt entry points of each physical CPU.

4. The virtual machine vCPU scheduling contention monitoring method based on eBPF according to claim 1, characterized in that, The step of synchronizing the statistical increments of the local cache to the global hash map, and generating vCPU scheduling contention monitoring data based on the statistical data of the global hash map, includes: At the end of the read copy update grace period, the statistical increment of each physical CPU's local cache is accumulated into the corresponding entry of the global hash map; Clear the statistical increment in the local cache, but retain the value of the popularity count field; Read the statistical data of the global hash mapping and combine it with the mapping relationship between virtual machine identifier and vCPU identifier to generate vCPU scheduling contention monitoring data.

5. The virtual machine vCPU scheduling contention monitoring method based on eBPF according to claim 2, characterized in that, The response to the scheduling Tick interrupt triggering, updating the heat value of each vCPU based on a sliding window, and adjusting the cache entries in the local cache, includes: Count the access records of each vCPU within the current Tick cycle and update the heat count value in the sliding window; Cache entries with a popularity value below the eviction threshold are removed from the storage area and their corresponding slots are added to the free slot list. Allocate free slots to non-cached vCPUs whose popularity values ​​reach the admission threshold and add them to the local cache storage area.

6. The virtual machine vCPU scheduling contention monitoring method based on eBPF according to claim 2, characterized in that, The parsing of the vCPU identifier and metric increment corresponding to the scheduling event is matched with the local cache entry of the current physical CPU, including: Extract the vCPU thread identifier and event type from the context information of the scheduling event, and calculate the metric increment corresponding to this event; Traverse the hot entries storage area of ​​the local cache using the vCPU's thread identifier as the matching key; Compare the consistency of thread identifiers to determine the cache hit status.

7. The virtual machine vCPU scheduling contention monitoring method based on eBPF according to claim 4, characterized in that, At the end of the read-copy update grace period, the statistical increment of each physical CPU's local cache is accumulated into the corresponding entry of the global hash map, including: Check the grace period status of the read copy update mechanism to confirm that all read-side critical sections have exited; Iterate through all hot entries in the local cache of each physical CPU and extract the corresponding statistical increments; The statistical increment is written to the corresponding vCPU entry in the global hash map through an atomic accumulation operation.

8. The virtual machine vCPU scheduling contention monitoring method based on eBPF according to claim 2, characterized in that, The method further includes: In response to the vCPU cross-core migration event, the statistical increment of the corresponding vCPU in the local cache of the migrated physical CPU is synchronized to the global hash map; Mark the cache entry of the corresponding vCPU in the physical CPU to be evicted; The migrated physical CPU accumulates the heat count of the corresponding vCPU in subsequent scheduling events, and is added to the local cache after reaching the admission threshold.

9. The virtual machine vCPU scheduling contention monitoring method based on eBPF according to claim 5, characterized in that, The method further includes: Collect the density of scheduling events within the unit window, and adjust the step size of the sliding window according to the density of scheduling events; When the scheduling event density increases, the sliding window step size is shortened; when the scheduling event density decreases, the sliding window step size is lengthened.

10. A virtual machine vCPU scheduling contention monitoring device based on eBPF, characterized in that, It includes a storage building module, an event handling module, and a data generation module; The storage building module is used to build a global hash map protected by a read-copy-update mechanism and a local cache corresponding to each physical CPU, and to attach scheduling event hooks and scheduling Tick hooks; The event handling module is used to respond to the scheduling event trigger by first updating the statistical increment of the corresponding vCPU in the local cache of the current physical CPU, updating the global hash mapping when the local cache is not hit, and updating the vCPU popularity ranking in the local cache and adjusting the cache entries in response to the scheduling Tick interrupt. The data generation module is used to synchronize the statistical increments of the local cache to the global hash map, and generate vCPU scheduling contention monitoring data based on the statistical data of the global hash map.

Images