A container adaptive resource scheduling method and system based on kernel enhancement

Abstract

The application provides a container adaptive resource scheduling method and system based on kernel enhancement, the method comprising: obtaining service semantic information of a container; encoding the service semantic information into a property combination recognizable by a kernel and injecting the property combination into the kernel, so that the kernel performs adaptive scheduling of CPU, memory and IO resources of processes in the container. The application realizes microsecond-level adaptation of process-level semantics in the container, adaptive resource scheduling of CPU-memory-IO combination and full-link inheritance under the premise of maintaining the top-level resource hard quota boundary of the container cgroup, and meets the needs of fine resource management of a cloud computing container cluster.

Description

Technical Field

[0001] This application belongs to the field of cloud computing container resource management technology, and in particular relates to a container adaptive resource scheduling method and system based on kernel enhancement. Background Technology

[0002] With the rapid development of cloud computing and cloud-native technologies, container technology has become a core support for modern cloud computing architecture. Existing container resource isolation and scheduling mechanisms are mainly implemented based on the Linux kernel's cgroup subsystem and namespace mechanism, allocating fixed resource shares to containers through static configuration of parameters such as `cpu.shares`, `memory.limit`, and `io.weight`. The kernel defaults to using the Completely Fair Scheduler (CFS) for process scheduling, allocating CPU time slices based on the process's virtual runtime, without distinguishing between task business attributes and load characteristics. Memory reclamation and I / O scheduling also employ a uniform, generic strategy, unaware of differentiated business load requirements. When business load changes, cgroup configurations must be modified through upper-layer controllers or manually. This adjustment process involves a long chain of virtual file system read / write operations, kernel parsing, and application activation, typically with latency in the thousands of seconds, failing to match the millisecond-level changes in business load. Furthermore, child processes forked within a container cannot inherit the resource scheduling attributes of their parent processes, requiring individual process reconfiguration, resulting in significant system overhead and potential semantic inconsistencies. In addition, scheduling CPU, memory, and I / O resources requires separate modifications to different cgroup subsystems, with long adjustment chains that prevent synchronous switching, leading to a mismatch between resource allocation and actual business needs. Summary of the Invention

[0003] To address the challenge of achieving microsecond-level adaptation of process-level semantics within containers, full-link inheritance, and adaptive resource scheduling of CPU-memory-IO combinations through kernel enhancements while maintaining the hard quota boundaries of container cgroup top-level resources, this application provides a container adaptive resource scheduling method and system based on kernel enhancements.

[0004] This application first provides a kernel-enhanced container adaptive resource scheduling method, including: Obtain the container's business semantic information; Business semantic information is encoded into kernel-recognizable attribute combinations and injected into the kernel, enabling the kernel to perform adaptive scheduling of CPU, memory, and I / O resources for processes within the container based on these attribute combinations. The kernel-recognizable attribute combinations include a workload_hint structure stored in the kernel process descriptor, prctl attribute combinations, and madvise memory policy combinations. The workload_hint structure is a kernel data structure that stores load characteristic information. The prctl attribute combinations are a set of process attributes set through the Linux system call prctl, and the madvise memory policy combinations are a set of memory access policies set through the Linux system call madvise.

[0005] Optionally, business semantic information is encoded into a combination of kernel-recognizable attributes and injected into the kernel, including: Generate a workload_hint structure based on business semantic information and write it into the kernel process descriptor; Generate prctl attribute combinations based on business semantic information and set them in the container's init process; Based on business semantic information, generate a combination of madvise memory strategies and apply them to the process memory region of the container.

[0006] Optionally, a workload_hint structure is generated based on business semantic information and written to the kernel process descriptor, including: Determine the level of latency sensitivity based on business semantic information; Determine the burst score based on business semantic information; Determine the level of I / O sensitivity based on business semantic information; A workload_hint structure is generated based on the latency sensitivity level, burst score, and I / O sensitivity level. The workload_hint structure is written to the kernel process descriptor via a system call.

[0007] Optionally, generate a combination of prctl attributes based on business semantic information and set it in the container's init process, including: The timer relaxation value is determined based on the latency sensitivity level; the I / O refresher flag is determined based on the I / O sensitivity level. Determine the memory locking ratio based on the memory sensitivity level; Generate a combination of prctl attributes based on the timer relaxation value, the IO refresher flag, and the memory lock ratio; The prctl system call sets the prctl property combination to the container's init process.

[0008] Optionally, a combination of madvise memory strategies is generated based on business semantic information and applied to the process memory region of the container, including: Determine the memory prefetching strategy based on the level of latency sensitivity; Determine the big page usage strategy based on memory sensitivity level; Determine the memory access pattern strategy based on the level of I / O sensitivity; A madvise memory strategy combination is generated based on the memory prefetching strategy, the big page usage strategy, and the memory access mode strategy. The madvise memory strategy is combined and applied to the process memory region of the container through the madvise system call.

[0009] Optionally, the kernel performs adaptive scheduling of CPU, memory, and I / O resources for processes within the container based on the aforementioned attribute combinations, including: The kernel scheduler adjusts the CPU scheduling priority and time allocation of processes based on the combination of the workload_hint structure and the prctl attribute; The kernel memory manager adjusts memory prefetching, reclamation, and big page usage strategies based on a combination of prctl attribute combinations and madvise memory policies. The kernel I / O scheduler adjusts the processing order and bandwidth allocation of I / O requests based on the combination of the workload_hint structure and the prctl attribute.

[0010] Optionally, the kernel scheduler adjusts the CPU scheduling priority and time allocation of processes based on the combination of the workload_hint structure and prctl attributes, including: The kernel scheduler adjusts the virtual runtime of processes based on their latency sensitivity level; The kernel scheduler adjusts the CPU quota limit for processes based on the burst score; The kernel scheduler adjusts the scheduling priority of processes based on the I / O refresher flag.

[0011] Optionally, the system receives a semantic switching signal, determines new business semantic information based on the semantic switching signal, encodes the new business semantic information into a new kernel-recognizable attribute combination and injects it into the kernel, and the kernel updates the resource scheduling strategy of the process within the container based on the new attribute combination.

[0012] Optionally, new business semantic information can be encoded into a new kernel-recognizable combination of attributes and injected into the kernel, including: Atomize the new prctl property combination settings to all processes of the container; The system retrieves memory region information for all processes within the container and applies the new madvise memory policy combination to the memory regions of all processes in batches using the process_vm_madvise system call. The process_vm_madvise system call is a system call in Linux used to batch modify the memory region access policies of multiple processes.

[0013] This application also provides a kernel-enhanced container adaptive resource scheduling system, including a semantic acquisition module, a semantic encoding injection module, and a kernel scheduling module. The semantic acquisition module is used to acquire the business semantic information of the container, the semantic encoding injection module is used to encode the business semantic information into a kernel-recognizable attribute combination and inject it into the kernel, and the kernel scheduling module is used to perform adaptive scheduling of CPU, memory, and I / O resources of processes within the container according to the attribute combination.

[0014] In the embodiments provided in this application, a kernel-native semantic-aware scheduling mechanism is constructed by introducing a `workload_hint` structure into the kernel as a unified carrier of business semantics, and combining `prctl` attribute combinations with `madvise` memory policy combinations. Business semantic information is encoded into three kernel-recognizable attributes and injected into the kernel. The kernel scheduler, memory manager, and I / O scheduler can directly read these attributes and perform differentiated processing without going through a user-space intermediate layer. The `workload_hint` structure guides the dynamic adjustment of kernel-space cgroup weights and the allocation of scheduling priorities. The `prctl` attribute combinations achieve end-to-end semantic transparency through the kernel's native fork mechanism, and the `madvise` memory policy combinations achieve fine-grained control at the memory region level. This allows the kernel to adjust resource allocation strategies according to changes in business load, reducing resource adjustment latency from seconds to microseconds. A single setting can cover all processes within the container, while simultaneously achieving synchronous scheduling of CPU, memory, and I / O resources. All operations are constrained by the kernel's native cgroup resource limitation mechanism, ensuring that container resource boundaries are not exceeded, thus improving cluster resource utilization while guaranteeing business performance. 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 general flowchart of the container adaptive resource scheduling method based on kernel enhancement in the embodiments of this application; Figure 2This is a flowchart of the semantic encoding injection sub-process in the embodiments of this application; Figure 3 This is a flowchart illustrating the generation of the workload_hint structure in an embodiment of this application. Figure 4 This is a flowchart illustrating the generation of prctl attribute combinations in an embodiment of this application. Figure 5 This is a flowchart of the madvise memory strategy combination generation sub-process in the embodiments of this application; Figure 6 This is a flowchart of the kernel adaptive scheduling sub-process in the embodiments of this application; Figure 7 This is a flowchart of the CPU scheduling priority and time allocation adjustment sub-process in the embodiments of this application; Figure 8 This is a flowchart of the semantic switching attribute injection sub-process in the embodiments of this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and technologies 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 may also be implemented in other embodiments without such specific details.

[0018] like Figure 1 As shown, the kernel-enhanced container adaptive resource scheduling method provided in this application includes: S101: Obtain the business semantic information of the container.

[0019] S102: Encode business semantic information into a kernel-recognizable attribute combination and inject it into the kernel, so that the kernel can perform adaptive scheduling of CPU, memory and I / O resources of the process in the container according to the attribute combination; wherein the kernel-recognizable attribute combination includes the workload_hint structure stored in the kernel process descriptor, the prctl attribute combination and the madvise memory policy combination. The workload_hint structure is a kernel data structure that stores load characteristic information. The prctl attribute combination is a set of process attributes set by the Linux system call prctl. The madvise memory policy combination is a set of memory access policies set by the Linux system call madvise.

[0020] It should be noted that existing technologies typically achieve resource scheduling only by modifying cgroup configurations, or by using prctl or madvise for single-dimensional optimization, without building a complete semantically aware adaptive scheduling system at the kernel level. Modifying cgroup configurations involves multiple stages, including the user-space controller, virtual file system, and kernel parsing, resulting in high latency and an inability to achieve fine-grained process-level control. Using prctl alone can only adjust some process attributes and cannot affect the core decision-making logic of the kernel scheduler or the resource weight allocation at the cgroup level. Using madvise alone can only optimize memory access policies and cannot achieve combined scheduling of CPU and I / O resources. This application adds a dedicated `workload_hint` structure to the kernel to carry business semantics and organically combines it with existing prctl and madvise mechanisms, enabling the kernel to directly perceive business load characteristics and adjust resource scheduling strategies, thus achieving truly kernel-enhanced container adaptive resource scheduling.

[0021] In this embodiment, the methods for obtaining container business semantic information include reading from the container image's metadata, reading from Pod annotations in the container orchestration platform, and reading from the container's environment variables. Business semantic information describes the resource requirements of business processes within the container, including latency sensitivity, memory sensitivity, IO sensitivity, and burst load levels. This business semantic information is encoded into kernel-recognizable attribute combinations and injected into the kernel. This transforms abstract business semantic information into executable attributes and policies natively supported by the kernel. These attributes and policies are directly stored in relevant kernel data structures, and the kernel directly reads these attribute values ​​when executing core logic such as scheduling, memory management, and IO processing. The kernel performs adaptive scheduling of CPU, memory, and IO resources for processes within the container based on the attribute combinations. Specifically, the kernel scheduler adjusts process scheduling priorities and CPU time allocation based on the `workload_hint` structure and `prctl` attribute combinations; the memory manager adjusts memory prefetching, reclamation, and large page usage policies based on the `madvise` memory policy combination and `prctl` attribute combination; and the IO scheduler adjusts the processing order and bandwidth allocation of IO requests based on the `workload_hint` structure and `prctl` attribute combinations.

[0022] At the kernel data structure design level, the `workload_hint` structure is added to the end of the `task_struct` structure and stored together with other process attributes. This design does not break the compatibility of existing kernel data structures and ensures that the `workload_hint` structure is fully bound to the process's lifecycle. When a process is created, the `workload_hint` structure is initialized to its default value; when a process is destroyed, the memory occupied by the `workload_hint` structure is released. Compared to extending the cgroup subsystem to carry business semantics, this design has lower memory overhead and faster access speed. Extending the cgroup subsystem requires creating new virtual file system nodes, increasing kernel complexity and memory consumption. However, by storing business semantics directly in the process descriptor, the kernel scheduler and resource manager can directly access it during the execution of core logic without going through virtual file system read / write operations.

[0023] At the system call implementation level, this application adds a dedicated system call for passing the `workload_hint` structure from user space to kernel space. This system call receives a pointer to the `workload_hint` structure from user space, performs parameter validation in kernel space, and then copies the structure content to the `task_struct` structure of the corresponding process. Parameter validation includes checking process permissions, structure size, and the value range of each field. Only processes with `CAP_SYS_RESOURCE` privileges can call this system call to modify their own or other processes' `workload_hint` structures; this permission control mechanism ensures system security. Compared to passing business semantics via netlink sockets or the proc filesystem, the dedicated system call offers lower latency and higher reliability. Netlink sockets require processing by the kernel network protocol stack, resulting in higher latency and potential packet loss; reading and writing to the proc filesystem requires parsing by the virtual filesystem, which is less efficient.

[0024] In the complete attribute injection process, business semantic information is first extracted from the container's metadata by the user-space semantic acquisition module and then passed to the semantic encoding module. The semantic encoding module converts the business semantic information into a `workload_hint` structure, `prctl` attribute combinations, and a `madvise` memory policy combination according to predefined mapping rules. Then, the semantic encoding module writes the `workload_hint` structure to the kernel process descriptor via a new system call, sets the `prctl` attribute combinations to the container's init process via the `prctl` system call, and applies the `madvise` memory policy combination to the process's memory region via dynamic link library injection. The entire injection process is completed during container startup without requiring any modifications to the business process, achieving non-intrusive adaptation to existing business logic.

[0025] In this embodiment, a `workload_hint` structure is generated based on business semantic information and written to the kernel process descriptor. This involves extracting load characteristic parameters from the business semantic information, filling them into the kernel-defined `workload_hint` structure, and then writing the structure to the corresponding field of the kernel process descriptor via a system call. The `workload_hint` structure is stored in the kernel's process descriptor and bound to the process's lifecycle. The kernel scheduler, memory manager, and I / O scheduler directly access this structure when executing core logic. A `prctl` attribute combination is generated based on the business semantic information and set in the container's `init` process. This converts the business semantic information into process attributes that can be set via the `prctl` system call. These attributes are directly stored in the process's `task_struct` structure and are inherited by child processes during process forking. A `madvise` memory policy combination is generated based on the business semantic information and applied to the container's process memory region. This converts the business semantic information into memory access policies that can be set via the `madvise` system call. These policies are applied to the process's virtual memory region, guiding the kernel on how to manage the memory pages in that region.

[0026] like Figure 2 As shown, business semantic information is encoded into a combination of attributes that the kernel can recognize and injected into the kernel, including: S103: Generate a workload_hint structure based on business semantic information and write it to the kernel process descriptor.

[0027] S104: Generate a combination of prctl attributes based on business semantic information and set it in the container's init process.

[0028] S105: Generate a combination of madvise memory strategies based on business semantic information and apply them to the process memory area of ​​the container.

[0029] In the design of the `workload_hint` structure, in addition to the three core fields of latency sensitivity level, burstiness score, and I / O sensitivity level, other fields can be extended according to actual needs, such as memory sensitivity level, CPU intensity level, and network sensitivity level. These fields together constitute a complete description of the workload characteristics, enabling the kernel to more comprehensively understand the resource requirements of the business. The memory sensitivity level describes the business's sensitivity to memory reclamation, the CPU intensity level describes the business's dependence on CPU computing resources, and the network sensitivity level describes the business's requirements for network latency and bandwidth. By extending these fields, the technical solution of this application can be applied to more types of business scenarios.

[0030] During the generation of prct attribute combinations, the semantic encoding module comprehensively calculates the value of each prct attribute based on multiple dimensions of the business semantic information. For example, the timer relaxation value depends not only on the latency sensitivity level but also on the burstiness score. For businesses with high burstiness, even if their latency sensitivity level is not the highest, the timer relaxation value will be appropriately reduced to ensure that the business can respond to bursty requests in a timely manner. The IO refresher label depends not only on the IO sensitivity level but also on the memory sensitivity level. For memory-sensitive businesses, labeling them as IO refreshers can exempt their anonymous pages during memory reclamation, reducing business performance jitter. The memory lock ratio is mainly determined based on the memory sensitivity level, while also considering the container's hard memory quota to ensure that the total locked memory does not exceed the container's memory limit.

[0031] During the application of madvise memory policy combinations, the semantic encoding module generates different policy combinations based on the memory access patterns of the business. For businesses primarily experiencing random access, such as database services, the MADV_RANDOM policy is enabled, instructing the kernel to adopt a read-ahead strategy suitable for random access. For businesses primarily experiencing sequential access, such as log backup services, the MADV_SEQUENTIAL policy is enabled, instructing the kernel to adopt a read-ahead strategy suitable for sequential access. For businesses with high memory access latency requirements, the MADV_WILLNEED and MADV_HUGEPAGE policies are enabled to pre-read memory pages and use transparent huge pages. For businesses with low memory access latency requirements, the MADV_DONTNEED and MADV_NOHUGEPAGE policies are enabled to prioritize the reclamation of memory pages and avoid memory waste caused by using transparent huge pages.

[0032] Compared to existing technologies that schedule CPU, memory, and I / O resources independently, this application achieves combined scheduling of CPU, memory, and I / O resources by simultaneously encoding business semantic information into combinations of three different types of attributes. When the business load changes, only a single semantic switch operation is needed to update CPU scheduling priority, memory management strategy, and I / O scheduling parameters simultaneously, avoiding the latency and inconsistency problems caused by adjusting different resources separately. For example, when the load on a database service increases, a single semantic switch can simultaneously increase its CPU scheduling priority, increase the memory locking ratio, and increase the I / O weight, enabling the database service to obtain more CPU, memory, and I / O resources and better cope with peak business loads.

[0033] In this embodiment, latency sensitivity levels are determined based on business semantic information, classifying services into different levels according to their requirements for response latency. A higher latency sensitivity level indicates a more stringent requirement for response latency. Bursting severity scores are also determined based on business semantic information, assigning corresponding scores to services according to the degree of fluctuation in business load. A higher bursting severity score indicates greater fluctuation in business load and a greater likelihood of sudden resource demands. I / O sensitivity levels are further determined based on business semantic information, classifying services into different levels according to their requirements for I / O response latency and bandwidth. A higher I / O sensitivity level indicates a more stringent requirement for I / O performance. A `workload_hint` structure is generated based on the latency sensitivity level, bursting severity score, and I / O sensitivity level. These three parameters are then filled into the corresponding fields of the `workload_hint` structure to form complete load characteristic information. The `workload_hint` structure is written to the kernel process descriptor via a system call. This involves calling a newly added kernel system call to pass the user-space generated `workload_hint` structure to the kernel, which then copies it to the process descriptor of the corresponding process.

[0034] like Figure 3 As shown, a workload_hint structure is generated based on business semantic information and written to the kernel process descriptor, including: S106: Determine the level of latency sensitivity based on business semantic information.

[0035] S107: Determine the burst score based on business semantic information.

[0036] S108: Determine the level of IO sensitivity based on business semantic information.

[0037] S109: Generate a workload_hint structure based on the latency sensitivity level, burst score, and I / O sensitivity level.

[0038] S110: Write the workload_hint structure to the kernel process descriptor via a system call.

[0039] For example, latency sensitivity levels can be divided into 1 to 5, where level 1 indicates the least sensitivity to latency and level 5 indicates the most sensitivity to latency. Burst rate scores can be divided into 1 to 5, where 1 indicates the most stable load and 5 indicates the greatest load fluctuation. I / O sensitivity levels can be divided into 1 to 5, where level 1 indicates the least sensitivity to I / O and level 5 indicates the most sensitivity to I / O. For database services, the latency sensitivity level is typically 5, the burst rate score is 3, and the I / O sensitivity level is 5. For batch backup services, the latency sensitivity level is typically 1, the burst rate score is 2, and the I / O sensitivity level is 2. For AI inference services, the latency sensitivity level is typically 4, the burst rate score is 5, and the I / O sensitivity level is 3. For microservice gateways, the latency sensitivity level is typically 4, the burst rate score is 4, and the I / O sensitivity level is 3. For big data computing services, the latency sensitivity level is usually 2, the burstiness score is 2, and the IO sensitivity level is 4.

[0040] In determining latency sensitivity levels, classification can be based on the type of business and the Service Level Agreement (SLA). For example, online transaction businesses requiring a P99 response latency of less than 10 milliseconds can be classified into Level 5 latency sensitivity levels; ordinary web businesses requiring a P99 response latency of less than 100 milliseconds can be classified into Level 3 latency sensitivity levels; and batch processing businesses without strict response latency requirements can be classified into Level 1 latency sensitivity levels. The classification criteria for latency sensitivity levels can be adjusted according to actual business needs to adapt to different application scenarios.

[0041] In determining the burst score, historical data on business load can be used for calculation. For example, by analyzing the fluctuations in CPU utilization, memory utilization, and IO utilization over the past week, the standard deviation and coefficient of variation of the load can be calculated, and then the burst score can be determined based on these statistical indicators. The greater the load fluctuation, the higher the standard deviation and coefficient of variation, and the higher the burst score. For AI inference services, the load typically exhibits significant burstiness; CPU utilization spikes sharply when there are inference requests and remains low when there are no inference requests, thus its burst score is usually high. For database services, the load is relatively stable, but fluctuations still occur during peak business periods, therefore its burst score is typically at a medium level.

[0042] In determining the level of IO sensitivity, it can be based on the type of IO operations and IO throughput requirements of the business. For example, for database services that mainly use random read and write operations, the requirements for IO response latency are very high, and the IO sensitivity level can be divided into level 5; for log backup services that mainly use sequential read and write operations, the requirements for IO throughput are high, but the requirements for IO response latency are low, and the IO sensitivity level can be divided into level 2; for compute-intensive scientific computing services, there are fewer IO operations, and the IO sensitivity level can be divided into level 1.

[0043] When generating the `workload_hint` structure, the semantic encoding module performs validity checks on the values ​​of each field to ensure they are within preset ranges. For example, latency sensitivity levels must be between 1 and 5, burstiness scores must be between 1 and 5, and I / O sensitivity levels must be between 1 and 5. If a field's value exceeds the preset range, the semantic encoding module sets it to its default value and logs a warning. Validation prevents invalid parameter values ​​from being injected into the kernel, which could lead to abnormal kernel behavior.

[0044] When writing the `workload_hint` structure to the kernel process descriptor via a system call, the kernel first checks the permissions of the calling process. Only processes with `CAP_SYS_RESOURCE` privileges can modify the `workload_hint` structure of other processes; ordinary processes can only modify their own `workload_hint` structure. The kernel also checks if the target process exists and if it is in an operable state. If the target process does not exist or has exited, the system call returns the corresponding error code. After completing parameter validation, the kernel copies the `workload_hint` structure passed from user space into the `task_struct` structure of the target process and sets a flag to notify the kernel scheduler and resource manager that the process's load characteristics have been updated.

[0045] In this embodiment, a timer relaxation value is determined based on the latency sensitivity level. This is done to set a corresponding timer relaxation value according to the service's requirements for timer triggering accuracy. A smaller timer relaxation value results in higher timer triggering accuracy and lower process scheduling wake-up latency, but it increases the number of timer interrupts and CPU overhead. An IO refresher flag is determined based on the IO sensitivity level. For services with high IO sensitivity, they are marked as IO refreshers, and the kernel prioritizes processing their IO requests and exempts their anonymous pages from memory reclamation. A memory lock ratio is determined based on the memory sensitivity level. This is done to set a corresponding memory lock ratio according to the service's sensitivity to memory reclamation. A higher memory lock ratio means that the proportion of the service process's anonymous pages locked in physical memory is higher, making them less likely to be reclaimed by the kernel. A prctl attribute combination is generated based on the timer relaxation value, IO refresher flag, and memory lock ratio. These parameters are then converted into corresponding prctl system call options and parameter values ​​to form a complete prctl attribute combination. The prctl system call sets the prctl attribute combination to the container's init process. This is done before or during the container's init process startup by calling the prctl system call to set the generated attribute combination into the init process's task_struct structure.

[0046] like Figure 4 As shown, the process generates a combination of prctl attributes based on business semantic information and sets it in the container's init process, including: S111: Determine the timer relaxation value based on the level of delay sensitivity.

[0047] S112: Determine the IO refresher flag based on the IO sensitivity level.

[0048] S113: Determine the memory locking ratio based on the memory sensitivity level.

[0049] S114: Generate a combination of prctl attributes based on the timer relaxation value, IO refresher flag, and memory lock ratio.

[0050] S115: Set prctl property combinations to the container's init process via the prctl system call.

[0051] Specifically, the timer relaxation value is set via the `PR_SET_TIMERSLACK` option of the `prctl` system call, in nanoseconds. The IO refresher flag is set via the `PR_SET_IO_FLUSHER` option of the `prctl` system call; a value of 1 indicates marking as an IO refresher, and a value of 0 indicates not marking. The memory lock ratio is set via the `PR_SET_MLOCK` option of the `prctl` system call; the parameter value represents the proportion of anonymous pages locked, ranging from 0 to 100. For example, for a latency sensitivity level of 5, the timer relaxation value can be set to 1000 nanoseconds; for an IO sensitivity level of 5, the IO refresher flag is set to 1; and for a memory sensitivity level of 4, the memory lock ratio is set to 80%.

[0052] In the kernel mechanism of timer relaxation, the Linux kernel's timer subsystem employs a relaxed timer design, allowing for a certain deviation in the timer's trigger time to reduce the number of timer interrupts and improve CPU utilization. The timer relaxation value is this maximum allowed deviation. When a process sets a timer relaxation value, the kernel adjusts the trigger times of all timers for that process to fall within a time window centered on the original trigger time and with the timer relaxation value as the radius. This allows multiple timers to trigger at the same time point, reducing the number of timer interrupts. For latency-sensitive applications, a smaller timer relaxation value ensures that timers trigger at precise times, enabling processes to be woken up promptly to handle requests and reducing response latency. However, a smaller timer relaxation value increases the number of timer interrupts, increasing CPU overhead. Therefore, an appropriate timer relaxation value needs to be set based on the latency sensitivity level of the application to achieve a balance between latency and CPU overhead.

[0053] In the kernel mechanism of I / O refresher marking, when a process is marked as an I / O refresher, the kernel performs special handling on it in several aspects. Regarding I / O scheduling, the kernel inserts I / O requests from I / O refresher processes at the front of the I / O request queue, prioritizing these requests and reducing I / O wait time. Regarding memory reclamation, when system memory is insufficient, the kernel prioritizes reclaiming memory pages from non-I / O refresher processes, exempting anonymous pages from I / O refresher processes. This is because I / O refresher processes are typically responsible for handling disk I / O operations; if their anonymous pages are reclaimed, it can cause page faults when processing I / O requests, requiring the process to reload pages from the swap partition, thus significantly increasing I / O latency. Marking I / O-sensitive applications as I / O refreshers can effectively reduce the impact of memory reclamation on I / O performance.

[0054] In the kernel's mechanism for managing memory locking ratios, the traditional `mlock` system call requires specifying a concrete memory address and length, making it unsuitable for locking all anonymous pages of a process. The `PR_SET_MLOCK` option, an extension of the `prctl` system call, sets the memory locking ratio for a process. Once a process sets its memory locking ratio, the kernel tracks the process's anonymous page allocation. When a process allocates a new anonymous page, the kernel checks if the currently locked ratio exceeds the set threshold. If it doesn't, the kernel locks the newly allocated anonymous page in physical memory; if it does, the newly allocated anonymous page is not locked. This approach eliminates the need to traverse the process's memory regions, making it more convenient and suitable for container environments. The total size of the memory lock is constrained by the container's `memory.max` hard quota. When a process attempts to lock memory exceeding the container's memory quota, the `prctl` system call returns an `ENOMEM` error, rejecting the lock request. This kernel mechanism ensures that memory locking will not cause container memory overflow issues.

[0055] In the inheritance mechanism of prctl attribute combinations, when the Linux kernel processes the fork system call, it completely copies most of the prctl attributes from the parent process's `task_struct` structure to the child process's `task_struct` structure. This mechanism is natively provided by the kernel and has extremely high efficiency and reliability. By setting prctl attribute combinations to the container's init process, a single setting takes effect across the entire process, avoiding the system overhead and semantic inconsistencies of setting attributes for each process individually. Compared to existing technologies that traverse all processes within the container using scripts and set attributes one by one, this inheritance mechanism is more efficient and reliable. Script traversal requires traversing the ` / proc` filesystem, reading process information one by one, and executing system calls, resulting in high system overhead and the possibility of some processes not having their attributes set, leading to semantic inconsistencies. The kernel's native inheritance mechanism, however, completes attribute copying during process creation, requiring no additional user-space operations, resulting in zero system overhead, and ensuring that all child processes have the same attributes as the parent process.

[0056] In this embodiment, a memory prefetching strategy is determined based on the latency sensitivity level. This involves determining whether the kernel needs to prefetch memory pages based on the service's memory access latency requirements. For services with high latency sensitivity, enabling the memory prefetching strategy can reduce page faults and lower memory access latency. For services with low latency sensitivity, disabling the memory prefetching strategy can avoid unnecessary memory bandwidth consumption. A large page usage strategy is determined based on the memory sensitivity level. This involves determining whether to use transparent huge pages based on the service's memory access speed requirements. Transparent huge pages can reduce the probability of TLB misses and improve memory access speed, but they will incur some allocation and merging overhead. A memory access mode strategy is determined based on the IO sensitivity level. This involves setting corresponding memory access strategies based on the service's IO access patterns. For random IO-intensive services, setting to random access mode can improve random IO performance; for sequential IO-intensive services, setting to sequential access mode can improve sequential IO throughput. A madvise memory strategy combination is generated based on the memory prefetching strategy, large page usage strategy, and memory access mode strategy. This involves converting these strategies into corresponding madvise system call options to form a complete madvise memory strategy combination. The madvise system call applies the madvise memory policy to the process memory region of the container. When memory is allocated to the process, the madvise system call applies the generated memory policy to the newly allocated memory region.

[0057] like Figure 5 As shown, a combination of madvise memory strategies is generated based on business semantic information and applied to the process memory region of the container, including: S116: Determine the memory prefetching strategy based on the level of latency sensitivity.

[0058] S117: Determine the big page usage strategy based on memory sensitivity level.

[0059] S118: Determine the memory access pattern strategy based on the level of IO sensitivity.

[0060] S119: Generate a madvise memory policy combination based on the memory prefetching policy, big page usage policy, and memory access mode policy.

[0061] S120: Apply the madvise memory strategy to the process memory region of the container via the madvise system call.

[0062] For example, the memory prefetching policy is set via the MADV_WILLNEED or MADV_DONTNEED options of the madvise system call. MADV_WILLNEED notifies the kernel that the process is about to access the memory region, and the kernel will prefetch the corresponding memory pages. MADV_DONTNEED notifies the kernel that the process no longer needs the memory region, and the kernel can preferentially reclaim the memory pages in that region. The big page usage policy is set via the MADV_HUGEPAGE or MADV_NOHUGEPAGE options of the madvise system call. MADV_HUGEPAGE notifies the kernel to use transparent huge pages for this memory region. MADV_NOHUGEPAGE notifies the kernel not to use transparent huge pages for this memory region. The memory access mode policy is set via the MADV_RANDOM or MADV_SEQUENTIAL options of the madvise system call. MADV_RANDOM notifies the kernel that the access mode for this memory region is random. MADV_SEQUENTIAL notifies the kernel that the access mode for this memory region is sequential.

[0063] In the kernel mechanism of memory prefetching, the Linux kernel's memory prefetching subsystem prefetches memory pages based on the process's memory access patterns to reduce page faults. By default, the kernel uses a sequential prefetching strategy; when a process accesses memory pages sequentially, the kernel prefetches multiple subsequent pages. However, for random access scenarios, the sequential prefetching strategy prefetches a large number of unnecessary pages, wasting memory bandwidth and physical memory. By setting the MADV_RANDOM option using the madvise system call, the kernel can be notified that the access pattern for this memory region is random, and the kernel will disable the sequential prefetching strategy, only prefetching the currently accessed pages to avoid unnecessary memory bandwidth consumption. By setting the MADV_WILLNEED option, the kernel can be notified that the process is about to access this memory region, and the kernel will preload the corresponding pages from disk into physical memory, reducing page faults during process access. By setting the MADV_DONTNEED option, the kernel can be notified that the process no longer needs this memory region, and the kernel will immediately reclaim the physical memory pages in that region, improving memory utilization.

[0064] In the kernel mechanism of bigpage usage strategies, transparent huge pages are a memory management mechanism provided by the Linux kernel that merges multiple 4KB small pages into a single 2MB or 1GB large page. Using bigpages can reduce page table size, decrease the probability of TLB misses, and improve memory access speed. However, the allocation and merging of bigpages incurs some overhead, and bigpage allocation may fail when system memory fragmentation is severe. Furthermore, the granularity of bigpages is relatively large, which can lead to memory waste for applications with low memory usage. Setting the MADV_HUGEPAGE option via the madvise system call can instruct the kernel to prioritize the use of bigpages for that memory region; setting the MADV_NOHUGEPAGE option can instruct the kernel not to use bigpages for that memory region. This allows for flexible selection of whether to use bigpages based on the application's memory access patterns and memory usage, achieving a balance between memory access speed and memory utilization.

[0065] In the implementation details of dynamic link library injection, this application uses the LD_PRELOAD environment variable to inject a custom dynamic link library. LD_PRELOAD is an environment variable provided by the Linux dynamic linker, allowing users to specify a dynamic link library that is loaded before all other dynamic link libraries. By writing a custom dynamic link library and hooking memory allocation and deallocation functions such as malloc, calloc, realloc, mmap, and munmap, the corresponding madvise policy can be applied to the memory region allocated by the process without modifying the business logic. The hook functions in the custom dynamic link library first call the original memory allocation function to obtain the memory address, then determine the corresponding madvise policy based on the current business semantic level, and call the madvise system call to apply the policy to the newly allocated memory region. For memory deallocation functions, the hook functions first call the original memory deallocation function to release the memory, and then clean up the relevant state information.

[0066] When handling different memory allocation scenarios, custom dynamic link libraries need to consider various situations. For example, for memory allocated by the `malloc` function, the hook function needs to determine whether to apply a big-page strategy based on the allocation size. For small memory allocations, using big pages would waste memory, so the `MADV_HUGEPAGE` strategy can be avoided; for larger memory allocations, using big pages can significantly improve memory access speed, so the `MADV_HUGEPAGE` strategy can be applied. For memory allocated by the `mmap` function, the hook function needs to determine which strategies to apply based on the mapping type and flags. For example, for anonymous mappings, memory prefetching, big-page usage, and memory access mode strategies can be applied; for file mappings, memory prefetching and memory access mode strategies are mainly applied.

[0067] In this embodiment, the kernel scheduler adjusts the CPU scheduling priority and time allocation of processes based on the combination of the `workload_hint` structure and `prctl` attributes. When enqueuing and scheduling tasks, the kernel scheduler reads the process's `workload_hint` structure and `prctl` attributes, and adjusts the process's scheduling parameters accordingly to ensure that different types of services receive CPU resources matching their needs. The kernel memory manager adjusts memory prefetching, reclamation, and big page usage strategies based on the combination of `prctl` attributes and the `madvise` memory policy. When handling memory allocation, prefetching, and reclamation operations, the kernel memory manager reads the process's `prctl` attributes and the `madvise` policy of the memory region, and performs differentiated memory management operations based on these attributes and policies. The kernel I / O scheduler adjusts the processing order and bandwidth allocation of I / O requests based on the combination of the `workload_hint` structure and `prctl` attributes. When processing I / O requests, the kernel I / O scheduler reads the `workload_hint` structure and `prctl` attributes of the process to which the request belongs, and adjusts the priority and bandwidth allocation of the I / O request accordingly to ensure that different types of services receive I / O resources matching their needs.

[0068] like Figure 6 As shown, the kernel performs adaptive scheduling of CPU, memory, and I / O resources for processes within the container based on the aforementioned attribute combinations, including: S121: The kernel scheduler adjusts the CPU scheduling priority and time allocation of processes based on the combination of the workload_hint structure and the prctl attribute.

[0069] S122: The kernel memory manager adjusts memory prefetching, reclamation, and big page usage strategies based on a combination of prctl attribute combinations and madvise memory policies.

[0070] S123: The kernel I / O scheduler adjusts the processing order and bandwidth allocation of I / O requests based on the combination of the workload_hint structure and the prctl attribute.

[0071] In the kernel implementation of CPU scheduling, this application extends the Completely Fair Scheduler (CFS) by adding load-aware logic to key nodes such as task enqueueing, task scheduling, and task dequeueing. When a task is enqueued, the scheduler reads the task's `workload_hint` structure and `prctl` attributes, adjusts the task's virtual runtime based on its latency sensitivity level, and adjusts the task's CPU quota limit based on its burst score. When a task is scheduled, the scheduler selects the next task to run based on its virtual runtime and scheduling priority. When a task is dequeued, the scheduler updates the task's virtual runtime and CPU usage statistics. Compared to existing technologies that schedule tasks solely based on virtual runtime, this load-aware scheduling method enables latency-sensitive tasks to obtain more CPU time slices, reducing their response latency.

[0072] In the kernel implementation of memory management, this application extends the memory reclamation subsystem, memory prefetching subsystem, and transparent huge page subsystem. In the memory reclamation subsystem, logic is added to adjust memory reclamation priority based on the process's `workload_hint` structure and `prctl` attributes. For processes with high latency sensitivity, the reclamation priority of their memory pages is increased, delaying reclamation; for processes with low latency sensitivity, the reclamation priority of their memory pages is decreased, prioritizing reclamation. In the memory prefetching subsystem, logic is added to adjust the prefetch window size based on the madvise policy of memory regions. For memory regions marked `MADV_RANDOM`, the prefetch window size is decreased; for memory regions marked `MADV_SEQUENTIAL`, the prefetch window size is increased. In the transparent huge page subsystem, logic is added to adjust the huge page allocation priority based on the madvise policy of memory regions. For memory regions marked `MADV_HUGEPAGE`, huge pages are allocated preferentially; for memory regions marked `MADV_NOHUGEPAGE`, huge pages are not allocated.

[0073] In the kernel implementation of I / O scheduling, this application extends mainstream I / O schedulers (including CFQ, Deadline, and Kyber) by adding logic to adjust I / O request priorities based on the process's `workload_hint` structure and `prctl` attribute. When a process submits an I / O request, the I / O scheduler reads the process's `workload_hint` structure and `prctl` attribute, adjusting the I / O request priority based on the I / O sensitivity level and the I / O refresher flag. For processes with high I / O sensitivity and processes marked as I / O refreshers, the priority of their I / O requests is increased, and these requests are processed first. Simultaneously, the I / O scheduler adjusts the I / O bandwidth allocation based on the process's I / O sensitivity level, allowing processes with high I / O sensitivity to receive more I / O bandwidth. Compared to existing technologies that schedule based solely on the type and submission order of I / O requests, this load-aware I / O scheduling method enables I / O-sensitive services to achieve better I / O performance.

[0074] In the three resource scheduling methods, the kernel simultaneously adjusts the allocation strategies for CPU, memory, and I / O resources based on business semantic information to ensure that the allocation of these three resources is mutually matched. For example, for latency-sensitive database services, the kernel will simultaneously increase their CPU scheduling priority, increase the memory locking ratio, and increase the I / O weight, enabling the database service to obtain sufficient CPU, memory, and I / O resources. If only the CPU scheduling priority is increased without increasing the memory locking ratio, the database service's memory pages may be reclaimed by the kernel, leading to page faults and impacting its performance; if only the I / O weight is increased without increasing the CPU scheduling priority, the database service may not be able to process I / O completion events in a timely manner, resulting in a backlog of I / O requests. By combining the scheduling of these three resources, resource bottlenecks can be avoided, and the overall performance of the system can be fully utilized.

[0075] In this embodiment, the kernel scheduler adjusts the virtual runtime of processes based on their latency sensitivity level. When a task is enqueued, the kernel scheduler adjusts the virtual runtime of the process according to its latency sensitivity level. The higher the latency sensitivity level, the larger the adjustment in virtual runtime, allowing the process to obtain CPU time slices more quickly. The kernel scheduler adjusts the CPU quota limit of processes based on their burst score. Based on the burst score, the kernel scheduler allows processes to exceed their cgroup's CPU quota limit for a short period to handle sudden load demands. The higher the burst score, the larger the allowed quota exceedance. The kernel scheduler adjusts the scheduling priority of processes based on their I / O refresher marking. The kernel scheduler appropriately increases the scheduling priority of processes marked as I / O refreshers, enabling them to process I / O completion events promptly and reducing I / O latency.

[0076] like Figure 7As shown, the kernel scheduler adjusts the CPU scheduling priority and time allocation of processes based on the combination of the workload_hint structure and prctl attributes, including: S124: The kernel scheduler adjusts the virtual runtime of processes based on the level of latency sensitivity.

[0077] S125: The kernel scheduler adjusts the CPU quota limit for processes based on the burst score.

[0078] S126: The kernel scheduler adjusts the scheduling priority of processes based on the I / O refresher flag.

[0079] Specifically, the kernel scheduler adds load-aware logic to the `enqueue_task_fair` function of the Fully Fair Scheduler. When a task is enqueued, the scheduler first checks the latency sensitivity level in the task's `workload_hint` structure. If the latency sensitivity level is higher than a preset threshold, the scheduler subtracts a corresponding amount from the task's virtual runtime. This amount is proportional to the latency sensitivity level and the scheduling cycle. This way, tasks with high latency sensitivity will have shorter virtual runtimes than other tasks, placing them earlier in the scheduling queue and enabling them to obtain CPU time slices more quickly. For tasks with a burst score higher than a preset threshold, the scheduler allocates additional CPU time budget for the current scheduling cycle. This budget is proportional to the burst score and the CPU quota cycle. Once the task has used up the additional budget, the scheduler restores its CPU quota to its original level, preventing it from continuously consuming resources from other containers.

[0080] In the burst quota management mechanism, the kernel maintains a burst quota budget for each cgroup. When a process's burst score exceeds a preset threshold, the kernel allocates additional CPU time to the process from the cgroup's burst quota budget. The size of the burst quota budget is proportional to the cgroup's CPU quota, defaulting to 50% of the CPU quota. When a process uses additional CPU time, the kernel deducts the corresponding time from the burst quota budget. Once the burst quota budget is exhausted, the process can no longer exceed its CPU quota limit. The kernel periodically replenishes the burst quota budget, with the replenishment cycle matching the CPU quota cycle. This ensures that processes receive sufficient CPU resources during burst loads without excessively consuming resources from other containers.

[0081] During the scheduling priority adjustment of I / O refresher processes, the kernel increases the scheduling priority of processes marked as I / O refreshers by one level. In the Completely Fair Scheduler (CFS), a process's scheduling priority is determined by its nice value; the lower the nice value, the higher the priority. The kernel decrements the nice value of I / O refresher processes by 1, increasing their scheduling priority. This allows I / O refresher processes to acquire CPU time slices more quickly, process I / O completion events promptly, and reduce I / O latency. Simultaneously, the kernel inserts the awakened I / O refresher process at the front of the scheduling queue within the I / O completion interrupt handler, ensuring it receives immediate scheduling.

[0082] In this embodiment, a semantic switching signal is received, and a signal handling function is registered for the container's init process at startup to handle externally sent semantic switching signals. The semantic switching signal triggers dynamic adjustments to business semantics to adapt to changes in business load. New business semantic information is determined based on the semantic switching signal, specifically by determining a new business semantic level or specific semantic parameters based on the signal number or parameters carried by the signal. The new business semantic information is encoded into a new kernel-recognizable attribute combination and injected into the kernel. Following the same rules as the initial encoding, the new business semantic information is converted into a new workload_hint structure, a new prctl attribute combination, and a new madvise memory policy combination, and injected into the kernel. The kernel updates the resource scheduling policy of processes within the container based on the new attribute combination. When the kernel scheduler, memory manager, and I / O scheduler detect changes in process attributes, they update the corresponding scheduling parameters and policies to match resource allocation with new business requirements.

[0083] In some embodiments, the method further includes: receiving a semantic switching signal, determining new business semantic information based on the semantic switching signal, encoding the new business semantic information into a new kernel-recognizable attribute combination and injecting it into the kernel, and updating the resource scheduling policy of the process within the container based on the new attribute combination.

[0084] For example, semantic switching signals can use Linux real-time signals. Each real-time signal corresponds to a preset business semantic level. When a business semantic switch is needed, the corresponding real-time signal is sent to the container's init process. Real-time signals have very low processing latency, meeting the requirements of millisecond-level load changes. Semantic switching signals can also carry custom semantic parameters for more flexible dynamic adjustments. For example, the signal can carry parameters such as a new latency sensitivity level, memory sensitivity level, and I / O sensitivity level, and the init process generates corresponding attribute and strategy combinations based on these parameters.

[0085] In the kernel flow of signal handling, when the init process receives a semantic switching signal, the kernel suspends the execution of the init process and jumps to a pre-registered signal handler function. The signal handler function first parses the signal number and its parameters to determine the new business semantic information. Then, it calls the semantic encoding module to encode the new business semantic information into a new kernel-recognizable attribute combination. Afterward, the signal handler function injects the new attribute combination into the kernel and broadcasts the semantic switching signal to all child processes within the container. Once all child processes have completed their attribute updates, the signal handler function returns, and the kernel resumes the execution of the init process. The entire signal handling process is atomic and cannot be interrupted by other signals, ensuring the consistency of the semantic switching process.

[0086] In the implementation principle of atomic updates, this application adopts signal broadcasting and batch updates to achieve atomic attribute updates for all processes within the container. Upon receiving a semantic switch signal, the init process sends the same semantic switch signal to all child processes within the container. Each child process, upon receiving the signal, atomically updates its own prctl attribute combination via a single prctl system call and atomically updates its own workload_hint structure via a newly added system call. Both the prctl and newly added system calls are atomic operations, ensuring that no intermediate states occur during attribute updates and preventing disruption to normal process operation. For memory policy updates, the init process batch updates the madvise policies of all process memory regions via the process_vm_madvise system call. The process_vm_madvise system call processes update requests for all memory regions in batches in kernel mode, ensuring that policies for all memory regions take effect simultaneously.

[0087] In ensuring state consistency during semantic switching, this application employs a version number mechanism to track process attribute versions. Each process's `task_struct` structure contains a semantic version number field; this number increments by 1 when a process's attributes are updated. The kernel scheduler, memory manager, and I / O scheduler check the process's semantic version number during core logic execution. If the version number changes, they reread the process's attributes and update the corresponding scheduling parameters and policies. This mechanism ensures that all kernel subsystems use the latest attribute values ​​for scheduling, avoiding state inconsistencies. Simultaneously, the init process waits for all child processes to complete attribute updates before returning to the signal handler, ensuring that all processes within the container have updated their attributes to the same version.

[0088] In the event-based semantic switching approach, in addition to triggering semantic switching via external signals, this application also supports semantic switching based on business monitoring metrics. Users can define semantic switching rules in the container's metadata. For example, when CPU utilization exceeds 80%, the latency sensitivity level can be increased by one level; when memory utilization exceeds 90%, the memory lock ratio can be increased to 100%. The semantic acquisition module periodically collects business operation metrics, and triggers semantic switching operations when the semantic switching rules are met. This semantic switching approach makes container resource scheduling more intelligent and better adapts to dynamic changes in business load.

[0089] In this embodiment, the new prctl attribute combination is atomically set to all processes in the container. The init process broadcasts a semantic switch signal to all child processes within the container. Upon receiving the signal, each child process atomically updates its own prctl attribute combination using a single prctl system call. The prctl system call is an atomic operation, ensuring that no intermediate states occur during the attribute update process, thus avoiding impact on the normal operation of the process. The memory region information of all processes within the container is obtained. The init process traverses all process IDs under the / proc directory, reads the maps file of each process, and obtains the start and end addresses of all memory regions. The new madvise memory policy combination is applied in batches to the memory regions of all processes using the process_vm_madvise system call. The kernel processes these requests in batches, modifying the policies of all memory regions at once, by passing the obtained memory region information and the new madvise memory policy combination to the process_vm_madvise system call.

[0090] like Figure 8 As shown, new business semantic information is encoded into a new set of kernel-recognizable attributes and injected into the kernel, including: S128: Atomize the new prctl property combination settings to all processes of the container.

[0091] S129: Obtain memory region information for all processes within the container, and apply the new madvise memory policy combination to the memory regions of all processes in batches through the process_vm_madvise system call. The process_vm_madvise system call is a system call in Linux used to batch modify the memory region access policies of multiple processes.

[0092] It's important to note that the traditional `madvise` system call can only modify the policy of the memory region of the current process. If the memory policy of multiple processes needs to be modified, the `madvise` system call must be called for each process individually. This requires traversing all processes, obtaining memory region information for each, and calling `madvise` for each process, resulting in high system overhead and latency. The `process_vm_madvise` system call allows a user-space process to modify the `madvise` policy of the memory regions of other processes. It can transmit information about multiple memory regions from multiple processes at once, allowing the kernel to process these requests in batches, significantly improving the speed of batch updates.

[0093] In the kernel implementation of the `process_vm_madvise` system call, this call accepts an array of process IDs, an array of memory regions, and a madvise policy parameter. The kernel first checks the permissions of the calling process, ensuring it has the `CAP_SYS_PTRACE` permission and that the target process and the calling process are in the same PID namespace. Then, the kernel iterates through each process in the process ID array and each memory region in the memory region array, checking the validity of each region. For valid memory regions, the kernel calls the internal `madvise` function to apply the specified policy to that region. The entire process is completed in kernel mode, without requiring multiple switches to user mode, thus offering high efficiency.

[0094] In the performance analysis of batch memory policy updates, we assume there are N processes within a container, and each process has M memory regions that need to have their madvise policies updated. Using the traditional madvise system call, NM system calls are required, with each call having a latency of approximately 1 microsecond, resulting in a total latency of approximately NM microseconds. Using the process_vm_madvise system call, only one system call is needed, allowing the kernel to batch process the updates of all N*M memory regions, with a total latency of approximately K microseconds, where K is a constant and not significantly related to N and M. For example, when N=100 and M=10, the total latency using the traditional madvise system call is approximately 1000 microseconds, while the total latency using the process_vm_madvise system call is approximately 50 microseconds, representing a 20-fold speed improvement. The advantages of the process_vm_madvise system call become even more pronounced as the number of processes and memory regions increases.

[0095] In the optimized memory region traversal approach, when the init process traverses process IDs under the / proc directory, it can obtain the root PID of the container's PID namespace by reading the / proc / self / status file, and then only traverse processes within that PID namespace, avoiding traversal of processes outside the container. Simultaneously, the init process can cache process memory region information. When semantic switches occur, it only updates the strategy for the changed memory regions, rather than updating the strategy for all memory regions. This caching mechanism reduces the number of memory regions that need to be processed, further improving the speed of batch updates.

[0096] In comparing other implementations of batch updating prctl attributes, besides signal broadcasting, batch updates can also be achieved through the kernel's process group operation interface. For example, all processes within a container can be added to the same process group, and then a new system call can be used to batch set the prctl attributes of all processes in the group. This method is more efficient, requiring only one system call to update the prctl attributes of all processes. However, this method requires modifying the kernel and adding new system calls, resulting in poor compatibility. Signal broadcasting, on the other hand, does not require modifying the core kernel interface; only signal handling logic needs to be implemented in user space, offering better compatibility and suitability for deployment on existing kernel versions.

[0097] This application embodiment further provides a kernel-enhanced container adaptive resource scheduling system, including a semantic acquisition module, a semantic encoding injection module, and a kernel scheduling module; The semantic acquisition module is used to acquire the business semantic information of the container. The semantic encoding and injection module is used to encode the business semantic information into a combination of attributes that the kernel can recognize and inject it into the kernel. The kernel scheduling module is used to perform adaptive scheduling of CPU, memory and I / O resources of the processes in the container according to the attribute combination. The kernel-recognizable attribute combination includes the workload_hint structure stored in the kernel process descriptor, the prctl attribute combination and the madvise memory policy combination. The workload_hint structure is a kernel data structure that stores load characteristic information. The prctl attribute combination is a set of process attributes set by the Linux system call prctl. The madvise memory policy combination is a set of memory access policies set by the Linux system call madvise.

[0098] In this embodiment, the semantic acquisition module can be a lightweight program that executes when the container starts. It reads the container image's metadata, the container orchestration platform's Pod annotations, and the container's environment variables to extract business semantic information. The semantic encoding injection module can be a standalone program that receives business semantic parameters from the semantic acquisition module, generates a `workload_hint` structure, `prctl` attribute combinations, and `madvise` memory policy combinations based on a predefined mapping table, and injects these attribute combinations into the kernel through corresponding system calls. The kernel scheduling module includes kernel-mode scheduler enhancements, memory manager enhancements, and I / O scheduler enhancements. These parts are directly integrated into the kernel and can perform resource scheduling operations based on the injected attribute combinations.

[0099] For example, the semantic acquisition module could be a shell script executed when the container starts, reading the container image's LABEL file and the container orchestration platform's Pod annotation files to extract business semantic information. The semantic encoding injection module could be a small C program that receives business semantic parameters from the semantic acquisition module, queries a predefined mapping table, and generates corresponding attribute and policy combinations. Then, it writes the `workload_hint` structure to the kernel process descriptor using a newly added kernel system call, sets the `prctl` attribute combinations to the container's init process using the `prctl` system call, and applies the `madvise` memory policy combinations to the process's memory region through dynamic link library injection. The various enhancements to the kernel scheduling module modify the CFS scheduler, memory reclamation subsystem, and IO scheduler, enabling them to perform differentiated resource scheduling based on the `workload_hint` structure and `prctl` attribute combinations.

[0100] In the interaction flow between modules, when the container starts, the container runtime first executes the prestart hook, which calls the semantic acquisition module. The semantic acquisition module reads the container's metadata, extracts business semantic information, and then passes this information to the semantic encoding and injection module. The semantic encoding and injection module generates kernel-recognizable attribute combinations based on a predefined mapping table and injects these attribute combinations into the kernel. Afterward, the container runtime starts the container's init process. The init process registers signal handlers and then executes `exec` to start the main business process. The main business process inherits all attributes from the init process, dynamic link libraries are loaded into it, and the madvise policy is applied to newly allocated memory regions. When a change in business semantics is needed, an external signal is sent to the init process. The init process's signal handler parses the signal, generates a new attribute combination, injects it into the kernel, and simultaneously broadcasts the signal to all child processes, causing them to update their own attributes. Upon detecting the attribute change, the kernel scheduling module updates its resource scheduling policy.

[0101] In the interface design between modules, the semantic acquisition module and the semantic encoding injection module exchange business semantic information via command-line parameters or environment variables. The semantic encoding injection module and the kernel exchange attribute combinations via system calls. The init process and its child processes exchange semantic switching notifications via signals. All interfaces between modules adopt standard Linux system interfaces, ensuring good compatibility and scalability. Users can replace or extend any module according to their needs without modifying the code of other modules.

[0102] In the error handling mechanism, if the semantic acquisition module cannot read the container's metadata, it will use the default business semantic information and log a warning. If the semantic encoding injection module fails to generate attribute combinations, it will return an error code, the prestart hook will terminate the container's startup, and log an error. When the kernel processes system calls, if parameter validation fails, it will return the corresponding error code, and the semantic encoding injection module will handle it accordingly. When the init process broadcasts a semantic switching signal, if a child process does not exist or has exited, it will ignore that child process and log a warning. A robust error handling mechanism ensures the stability and reliability of the system.

[0103] In the implementation of logging and monitoring functions, each module records detailed log information, including business semantic information, the generation process of attribute combinations, the results of attribute injection, and the semantic switching process. This log information helps users troubleshoot problems and understand the system's operational status. Simultaneously, this application also provides a monitoring interface, allowing users to obtain information such as the container's business semantic level, resource scheduling parameters, and performance metrics by reading relevant files in the / proc file system. This monitoring information can be integrated into existing monitoring systems to achieve real-time monitoring of container resource scheduling.

[0104] In comparing different deployment methods, the technical solution of this application can adopt multiple deployment approaches. The first approach is to package the semantic acquisition module, semantic encoding injection module, and dynamic link library into a container image, which runs when the container starts. The advantage of this approach is its simplicity; it doesn't require modification of the container runtime or container orchestration platform. The disadvantage is that it requires modification of the container image, and existing container images need to be rebuilt. The second approach is to deploy each module as a DaemonSet on each node. When the container starts, the programs in the DaemonSet inject attribute combinations into the container. The advantage of this approach is that it doesn't require modification of the container image and is suitable for existing containers. The disadvantage is that deployment is relatively complex and requires additional DaemonSet resources. The third approach is to integrate each module into the container runtime, which performs semantic acquisition and attribute injection operations when the container starts. The advantage of this approach is its highest efficiency and complete transparency to the user. The disadvantage is that it requires modification of the container runtime code and has poor compatibility.

[0105] In this embodiment, a container with a database service deployed is used as an example to illustrate the implementation process of this solution. The container's cgroup hard quota is 4 CPU cores, 8GB memory, and 200MB / s IO. The database service is a latency-sensitive and IO-sensitive service, and auxiliary processes such as log backup and data statistics run within the container.

[0106] First, build the database container image. Add a business semantic configuration tag to the image build file, specifying the latency sensitivity level, memory sensitivity level, IO sensitivity level, and burst load level. Simultaneously, copy the executable files and dynamic link libraries of the semantic acquisition module, semantic encoding injection module, attribute setting module, and memory policy application module into the image. Set the container's entry point to the executable file of the semantic acquisition module, with the database service's startup command as the command parameter.

[0107] Then, the container is deployed to the container orchestration platform. The container orchestration platform creates a Pod, and the container executes the prestart hook at runtime. The prestart hook calls the semantic acquisition module to read the business semantic information in the container image tag, obtaining the latency sensitivity level 5, memory sensitivity level 4, IO sensitivity level 5, and burst load level 3.

[0108] The semantic acquisition module passes business semantic information to the semantic encoding injection module. The semantic encoding injection module queries a predefined mapping table to generate corresponding kernel-recognizable attribute combinations. The `workload_hint` structure contains latency sensitivity level 5, burstiness score 3, and IO sensitivity level 5. The `prctl` attribute combination includes a timer relaxation value of 1000 nanoseconds, an IO refresher flag of 1, a memory lock ratio of 80%, and inheritance control attributes of 0. The `madvise` memory policy combination includes the memory prefetching policy `MADV_WILLNEED`, the big page usage policy `MADV_HUGEPAGE`, and the memory access mode policy `MADV_RANDOM`.

[0109] The semantic encoding injection module writes the `workload_hint` structure into the kernel process descriptor of the container's `init` process via a newly added kernel system call. Then, it sets the `prctl` attributes to the upcoming `init` process using the `prctl` system call. After the `init` process starts, it registers signal handlers and becomes the parent process of all processes within the container. Then, the `init` process executes `exec` to start the database master process. The database master process inherits all `prctl` attributes and the `workload_hint` structure from the `init` process.

[0110] The database main process forks multiple worker threads, I / O threads, and monitoring threads. When the Linux kernel handles the fork system call, it copies the `prctl` attribute and `workload_hint` structure from the database main process's `task_struct` structure to the `task_struct` structures of all child threads. All child threads have the same semantic attributes as the main process, requiring no additional processing.

[0111] The memory policy application module is loaded into the database process via environment variables. When the database process calls malloc or mmap to allocate memory, the hook function in the dynamic link library calls the madvise system call to apply the corresponding memory policy to the newly allocated memory region. For example, when the database allocates a memory region for storing data, the hook function calls the madvise system call to notify the kernel to pre-read the region, use huge pages, and adopt random access mode.

[0112] A log backup process starts within the container. Upon startup, this process sets the inheritance control attribute to 1 via the `prctl` system call. Therefore, child processes forked by this process will not inherit business semantic attributes and will use the system default attributes. This way, the log backup process will not consume resources reserved for the database service, avoiding any impact on database performance.

[0113] The kernel scheduler reads the database process's `workload_hint` structure and `prctl` attribute combination, adjusting its CPU scheduling priority and time allocation. Because the database process has a latency sensitivity level of 5, the kernel scheduler deducts a corresponding amount from its virtual runtime when enqueuing the task, granting it priority in resource contention. Because the database process has a burstability score of 3, the kernel scheduler allows it to exceed a certain percentage of its CPU quota limit for short periods to handle sudden surges in query requests. Since the database process is marked as an I / O refresher, the kernel scheduler appropriately increases its scheduling priority, enabling it to handle I / O completion events promptly.

[0114] The kernel memory manager reads the database process's `prctl` attribute combination and the `madvise` memory policy combination of memory regions, and adjusts the memory management strategy accordingly. For memory regions marked `MADV_WILLNEED`, the kernel pre-fetches the corresponding memory pages to reduce page faults. For memory regions marked `MADV_HUGEPAGE`, the kernel uses transparent huge pages to improve memory access speed. For processes with a memory locking ratio of 80%, the kernel locks 80% of their anonymous pages to prevent them from being reclaimed. When system memory is insufficient, the kernel memory manager prioritizes reclaiming memory pages from processes with low latency sensitivity, delaying the reclamation of memory pages from database processes.

[0115] The kernel I / O scheduler reads the database process's `workload_hint` structure and `prctl` attribute combination to adjust the processing order and bandwidth allocation of I / O requests. Since the database process's I / O sensitivity level is 5, the kernel I / O scheduler will increase its I / O weight and allocate more I / O bandwidth. Because the database process is marked as an I / O refresher, the kernel I / O scheduler will prioritize its I / O requests, reducing I / O wait time.

[0116] When peak business periods arrive and a temporary increase in the database's semantic level is required, operations personnel send corresponding real-time signals to the container's init process via execution commands from the container orchestration platform. Upon receiving the signal, the init process determines the new business semantic level based on the signal number. The semantic encoding injection module generates a new kernel-recognizable attribute combination. The new prctl attribute combination adjusts the timer relaxation value to 500 nanoseconds and the memory lock ratio to 100%. The new madvise memory policy combination remains unchanged.

[0117] The semantic encoding injection module first updates the `workload_hint` structure of the init process using a newly added kernel system call. Then, it updates the `prctl` attribute combination of the init process using the `prctl` system call. Next, the init process broadcasts a real-time signal to all child processes within the container. Upon receiving the signal, all database worker threads atomically update their own `prctl` attribute combinations using a single `prctl` system call and update their own `workload_hint` structure using the newly added kernel system call. Simultaneously, the init process obtains the memory region information of all processes within the container and batch updates the memory policy combination of all processes using the `process_vm_madvise` system call. The entire switchover process is completed in a very short time, with no impact on the database operations.

[0118] After the switchover, the database timer relaxation value decreased, further reducing scheduling wake-up latency. The memory lock ratio increased, with all anonymous pages locked in physical memory and not reclaimed by the kernel. The kernel scheduler, based on the new `workload_hint` structure and `prctl` attribute combination, further increased the scheduling priority and CPU quota limit for the database process. The kernel memory manager, based on the new `prctl` attribute combination, strengthened memory protection for the database process. The kernel I / O scheduler, based on the new `workload_hint` structure, further increased the I / O weight and priority of the database process. Database response latency decreased, enabling better handling of peak business loads.

[0119] After the peak business period ends, the operations and maintenance personnel send another real-time signal to the init process to restore the database's semantic level to its original level. The init process executes the same switchover procedure, restoring the kernel-recognizable attribute combinations to their original values. The entire switchover process is also completed in a very short time, and the database performance returns to normal levels.

[0120] Throughout the process, all operations are constrained by the container's cgroup hard quotas. When the database process attempts to lock memory exceeding the container's memory quota, the `prctl` system call returns an error, rejecting the lock request. When the database's CPU utilization reaches the container's CPU quota limit, the kernel scheduler strictly limits its CPU usage time to prevent exceeding the hard quota. When the database's I / O bandwidth reaches the container's I / O quota limit, the kernel I / O scheduler rate-limits to prevent exceeding the I / O hard quota.

[0121] It should be noted that the technical solution in this application does not require modification of the upper-layer business code. Only the corresponding modules and configurations need to be added to the container image to achieve non-intrusive optimization of existing business operations. Furthermore, this solution is compatible with the existing container ecosystem and kernel version, requiring no large-scale modifications to the container orchestration platform or kernel, and possesses excellent deployability and maintainability.

[0122] Furthermore, the technical solution of this application can be customized according to different business types. The predefined mapping table can be adjusted according to the specific needs of the business, assigning different attribute and strategy combinations to different types of businesses. For example, for AI inference businesses, its burstiness score can be increased, allowing it to exceed more CPU quotas in a short period of time; for big data batch processing businesses, its latency sensitivity level can be reduced to improve CPU utilization.

[0123] In this embodiment, the enhancements to the kernel scheduler are modifications based on the existing Completely Fair Scheduler, without altering the scheduler's core architecture or fairness principles. When a task is enqueued, the scheduler checks its `workload_hint` structure. For tasks with high latency sensitivity, its virtual runtime is adjusted appropriately to grant them priority scheduling rights. This adjustment is limited and will not cause starvation for other tasks. For tasks with high burstiness, the scheduler allocates additional CPU time within the current scheduling cycle, reclaiming it after the burst ends to avoid long-term resource hogging by other containers.

[0124] The enhancements to the memory reclamation subsystem are modifications to the existing memory reclamation mechanism, without altering the basic memory reclamation process. When reclaiming memory, the subsystem checks the combination of the `workload_hint` structure and `prctl` attributes of the process owning the memory page. For memory pages used by processes with high latency sensitivity, their reclamation priority is appropriately increased, and reclamation is delayed; for memory pages used by processes with low latency sensitivity, their reclamation priority is appropriately decreased, and they are reclaimed first. This adjustment prioritizes ensuring the memory needs of critical business processes when system memory is insufficient, reducing performance fluctuations.

[0125] The enhancements to the I / O scheduler are modifications made to the existing I / O scheduler without changing its core algorithm. When processing I / O requests, the scheduler checks the combination of the `workload_hint` structure and `prctl` attributes of the process to which the request belongs. For I / O requests from processes with high I / O sensitivity, their priority is appropriately increased for priority processing; for I / O requests from processes with low I / O sensitivity, their priority is appropriately decreased for delayed processing. This adjustment ensures the I / O performance of critical business processes and avoids interference from non-critical I / O requests.

[0126] In this embodiment, the acquisition and encoding of business semantic information are completed in user space, offering good flexibility and scalability. Users can develop custom semantic acquisition and encoding modules according to their needs, supporting more business semantic parameters and more complex encoding rules. For example, a machine learning-based semantic encoding module can be developed to dynamically adjust the business semantic level based on real-time operational data, achieving more intelligent resource scheduling.

[0127] It should be noted that the technical solution of this application is applicable not only to container environments, but also to virtual machine environments and physical machine environments. In a virtual machine environment, business semantic information can be passed to the virtual machine kernel to achieve resource scheduling optimization within the virtual machine. In a physical machine environment, this solution can be directly deployed in the physical machine kernel to achieve resource scheduling optimization for multiple processes on the physical machine.

[0128] Furthermore, the technical solution of this application can be used in conjunction with the resource scheduling mechanism of existing container orchestration platforms. Container orchestration platforms can perform node scheduling and scaling of containers based on the overall resource status of the cluster. The technical solution of this application can perform fine-grained resource scheduling on a single node based on the business semantic information within the container. The two work together to achieve two-level resource scheduling at both the cluster and node levels, further improving the cluster's resource utilization and business performance.

[0129] In this embodiment, all kernel-mode modifications maintain compatibility with existing kernel interfaces and will not affect the normal operation of existing applications. Users can gradually deploy this solution without modifying existing applications, first testing it on non-critical business applications to verify its effectiveness before promoting it to critical business applications.

[0130] Those skilled in the art will understand that the scope of protection of this application is not limited to the specific embodiments described above. Any modifications, equivalent substitutions, or improvements based on the technical solutions of this application should be included within the scope of protection of this application.

Claims

1. A container adaptive resource scheduling method based on kernel enhancement, characterized in that, include: Obtain the container's business semantic information; Business semantic information is encoded into a combination of attributes that the kernel can recognize and injected into the kernel, so that the kernel can perform adaptive scheduling of CPU, memory and I / O resources of processes in the container according to the combination of attributes. The kernel-recognizable attribute combinations include the workload_hint structure stored in the kernel process descriptor, prctl attribute combinations, and madvise memory policy combinations. The workload_hint structure is a kernel data structure that stores workload characteristic information. The prctl attribute combinations are a set of process attributes set through the Linux system call prctl. The madvise memory policy combinations are a set of memory access policies set through the Linux system call madvise.

2. The method according to claim 1, characterized in that, Encode business semantic information into a combination of attributes that the kernel can recognize and inject it into the kernel, including: Generate a workload_hint structure based on business semantic information and write it into the kernel process descriptor; Generate prctl attribute combinations based on business semantic information and set them in the container's init process; Based on business semantic information, generate a combination of madvise memory strategies and apply them to the process memory region of the container.

3. The method according to claim 2, characterized in that, Generate a workload_hint structure based on business semantic information and write it to the kernel process descriptor, including: Determine the level of latency sensitivity based on business semantic information; Determine the burst score based on business semantic information; Determine the level of I / O sensitivity based on business semantic information; A workload_hint structure is generated based on the latency sensitivity level, burst score, and I / O sensitivity level. The workload_hint structure is written to the kernel process descriptor via a system call.

4. The method according to claim 2, characterized in that, Generate prctl attribute combinations based on business semantic information and set them in the container's init process, including: The timer relaxation value is determined based on the level of delay sensitivity; I / O refresher flags are determined based on the level of I / O sensitivity. The memory locking ratio is determined based on the memory sensitivity level; the memory sensitivity level is used to describe the degree to which the service is sensitive to memory reclamation. Generate a combination of prctl attributes based on the timer relaxation value, the IO refresher flag, and the memory lock ratio; The prctl system call sets the prctl property combination to the container's init process.

5. The method according to claim 2, characterized in that, Based on business semantic information, a combination of madvise memory strategies is generated and applied to the process memory region of the container, including: Determine the memory prefetching strategy based on the level of latency sensitivity; Determine the big page usage strategy based on memory sensitivity level; Determine the memory access pattern strategy based on the level of I / O sensitivity; A madvise memory strategy combination is generated based on the memory prefetching strategy, the big page usage strategy, and the memory access mode strategy. The madvise memory strategy is combined and applied to the process memory region of the container through the madvise system call.

6. The method according to claim 1, characterized in that, The kernel performs adaptive scheduling of CPU, memory, and I / O resources for processes within the container based on the aforementioned attribute combinations, including: The kernel scheduler adjusts the CPU scheduling priority and time allocation of processes based on the combination of the workload_hint structure and the prctl attribute; The kernel memory manager adjusts memory prefetching, reclamation, and big page usage strategies based on a combination of prctl attribute combinations and madvise memory policies. The kernel I / O scheduler adjusts the processing order and bandwidth allocation of I / O requests based on the combination of the workload_hint structure and the prctl attribute.

7. The method according to claim 6, characterized in that, The kernel scheduler adjusts the CPU scheduling priority and time allocation of processes based on the combination of the workload_hint structure and prctl attributes, including: The kernel scheduler adjusts the virtual runtime of processes based on their latency sensitivity level; The kernel scheduler adjusts the CPU quota limit for processes based on the burst score; The kernel scheduler adjusts the scheduling priority of processes based on the I / O refresher flag.

8. The method according to claim 1, characterized in that, The method further includes: receiving a semantic switching signal, determining new business semantic information based on the semantic switching signal, encoding the new business semantic information into a new kernel-recognizable attribute combination and injecting it into the kernel, and updating the resource scheduling strategy of the process in the container based on the new attribute combination.

9. The method according to claim 8, characterized in that, Encode new business semantic information into a new set of kernel-recognizable attributes and inject it into the kernel, including: Atomize the new prctl property combination settings to all processes of the container; The system retrieves memory region information for all processes within the container and applies the new madvise memory policy combination to the memory regions of all processes in batches using the process_vm_madvise system call. The process_vm_madvise system call is a system call in Linux used to batch modify the memory region access policies of multiple processes.

10. A container adaptive resource scheduling system based on kernel enhancement, characterized in that, It includes a semantic acquisition module, a semantic encoding and injection module, and a kernel scheduling module; The semantic acquisition module is used to acquire the business semantic information of the container. The semantic encoding and injection module is used to encode the business semantic information into a combination of attributes that the kernel can recognize and inject it into the kernel. The kernel scheduling module is used to perform adaptive scheduling of CPU, memory and I / O resources of the processes in the container according to the attribute combination. The kernel-recognizable attribute combination includes the workload_hint structure stored in the kernel process descriptor, the prctl attribute combination and the madvise memory policy combination. The workload_hint structure is a kernel data structure that stores load characteristic information. The prctl attribute combination is a set of process attributes set by the Linux system call prctl. The madvise memory policy combination is a set of memory access policies set by the Linux system call madvise.

Images