Resource management method, device, equipment, medium and product of operating system kernel

Abstract

The application discloses a resource management method and device of an operating system kernel, equipment, a medium and a product, relates to the technical field of resource management, and comprises the following steps: integrating a computing power pool and a memory pool into a unified initialization resource pool, realizing resource scheduling through a resource allocation primitive, avoiding cross coordination among multiple modules, and improving coordination efficiency; resource allocation, isolation and recovery are all executed through independent primitives, thereby guaranteeing the stability of resource adjustment; the resource isolation primitive is executed through a hardware isolation mechanism, resource access among different tasks can be blocked from the physical layer, and the safety isolation effect is guaranteed; the whole resource management process is completed through native primitives in the operating system kernel state, without the need of calling a user state component to participate in scheduling or management, the switching overhead of the user state and the kernel state and the central processing unit resources occupied by the running of the user state component are avoided, and the overall consumption is reduced.

Description

Technical Field

[0001] This application relates to the field of resource management technology, and in particular to a method, apparatus, device, medium and product for managing resources in an operating system kernel. Background Technology

[0002] In the process of large-scale development of scenarios such as cloud computing, artificial intelligence training, and real-time data processing, the pooling and sharing of computing power and memory resources and elastic scheduling have become core requirements to support the efficient operation of these scenarios, which puts forward higher requirements for the coordination, stability, security and performance adaptability of resource management technologies.

[0003] However, in the process of managing computing and memory resources, related technologies suffer from low coordination efficiency and fail to meet timeliness requirements. The independent management modules of the central processing unit (CPU), graphics processing unit (GPU), and memory, along with the unified computing device architecture and inconsistent memory access, necessitate multi-module collaboration for cross-resource scheduling. The process of destroying old resources and creating new ones has resource vacuum periods, lacks atomicity guarantees, and is prone to scheduling interruptions or data loss. Software isolation carries the risk of privilege escape, while hardware isolation incurs performance degradation, making it difficult to balance security and efficiency. Insufficient adaptation to hardware features such as CPU cache allocation, GPU grouping, and memory encryption prevents cache isolation, leading to task performance fluctuations. Scheduling mechanisms relying on user-space components require interaction between user and kernel modes, resulting in excessive CPU resource consumption. Therefore, the shortcomings of related computing and memory resource management technologies in terms of collaboration efficiency, atomicity, isolation effectiveness, hardware adaptation, and scheduling performance have become key bottlenecks restricting the large-scale development of cloud computing and artificial intelligence training scenarios, necessitating a novel resource management solution to address these issues. Summary of the Invention

[0004] This application provides a resource management method, apparatus, device, medium, and product for an operating system kernel, to at least solve the problems in computing power and memory resource management, such as low efficiency of cross-independent module scheduling and coordination, lack of atomicity in resource adjustment leading to problems, difficulty in balancing security and efficiency, insufficient hardware feature adaptation causing performance fluctuations, and reliance on user-mode components consuming central processing unit resources.

[0005] This application provides a resource management method for an operating system kernel, comprising: executing a resource allocation primitive in response to a request from a target task, determining a target logical resource unit from an initialization resource pool, and allocating the target logical resource unit to the target task; the initialization resource pool is a resource pool of the operating system kernel, including a computing power pool and a memory pool; the target logical resource unit includes a computing core group or a memory block; executing a resource isolation primitive to isolate the target logical resource unit from the logical resource units corresponding to other tasks through a hardware isolation mechanism; the other tasks are any tasks other than the target task; running the target task based on the target logical resource unit; and executing a resource reclamation primitive when the target task terminates to release the target logical resource unit back to the initialization resource pool.

[0006] This application also provides a resource management device for an operating system kernel, comprising:

[0007] The resource allocation module is used to execute resource allocation primitives in response to the request of the target task, determine the target logical resource unit from the initialization resource pool, and allocate the target logical resource unit to the target task; the initialization resource pool is the resource pool of the operating system kernel, including the computing power pool and the memory pool; the target logical resource unit includes computing core groups or memory blocks;

[0008] The resource isolation module is used to execute resource isolation primitives, which use hardware isolation mechanisms to isolate the target logical resource unit from the logical resource units corresponding to other tasks; other tasks are any tasks other than the target task.

[0009] The task execution module is used to run target tasks based on target logical resource units;

[0010] The resource reclamation module is used to execute resource reclamation primitives when the target task terminates, releasing the target logical resource unit back to the initialization resource pool.

[0011] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the resource management method of the operating system kernel when executing the computer program.

[0012] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the resource management method of the above-described operating system kernel.

[0013] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the resource management method of the operating system kernel described above.

[0014] This application integrates the computing power pool and memory pool into a unified initialization resource pool. Resource scheduling through resource allocation primitives achieves a single entry point, avoiding cross-coordination between multiple modules, reducing scheduling link length and communication overhead, and improving coordination efficiency. Resource allocation, isolation, and reclamation are all executed through independent primitives. The operation logic of each primitive is encapsulated into indivisible atomic steps, ensuring that there are no issues such as inconsistent states or ambiguous resource ownership throughout the entire lifecycle of resources from allocation to release, thus guaranteeing the stability of resource adjustments. Resource isolation primitives are executed through a hardware isolation mechanism, eliminating the need for complex permission checks or virtual isolation technologies at the software level, thus physically blocking resources between different tasks. Access ensures secure isolation while reducing performance overhead from software isolation, achieving a balance between security and efficiency. The initialization of the resource pool directly corresponds to the computing cores and memory blocks at the hardware level. Resource allocation primitives can directly map hardware resource units, avoiding resource conversion overhead between user mode and kernel mode, fully adapting to hardware characteristics, and reducing performance fluctuations caused by improper adaptation. The entire resource management process (allocation, isolation, operation, and reclamation) is completed in the operating system kernel mode through native primitives, without calling user-mode components to participate in scheduling or management. This completely avoids the switching overhead between user mode and kernel mode and the CPU resources occupied by user-mode components, reducing overall consumption. Attached Figure Description

[0015] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only 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 A schematic diagram illustrating the specific hardware architecture upon which the execution of an operating system kernel resource management method provided in this application embodiment depends;

[0017] Figure 2 A flowchart illustrating a resource management method for an operating system kernel provided in an embodiment of this application;

[0018] Figure 3 A schematic diagram of the structure of a resource management device for an operating system kernel provided in an embodiment of this application;

[0019] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0021] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0022] To more clearly illustrate the embodiments of this application, the technical terms used in the embodiments will be briefly introduced below:

[0023] Operating system primitives (OS Primitives) are non-interruptible sequences of atomic operations in the operating system kernel, used to implement core system functions.

[0024] The Central Processing Unit (CPU) is the core computing unit of a computer's central processing unit, serving as the fundamental hardware module for executing instructions and processing data. Each core can independently schedule tasks, supports multi-threaded parallel computing, and undertakes core tasks such as logical control and data processing for the system and applications.

[0025] The Graphics Processing Unit Streaming Multiprocessor (GPU SM) is the core computing unit in the GPU architecture. Each SM contains multiple unified computing device architecture cores or stream processors, supports large-scale parallel thread scheduling, and is the core component that provides the GPU with efficient parallel computing capabilities.

[0026] Non-Uniform Memory Access (NUMA) nodes are hardware topology units in multiprocessor systems, characterized by inconsistent memory access latency. Each NUMA node typically contains a set of CPU cores, local memory, and a memory controller. CPUs within a node access local memory faster, while accessing memory across nodes incurs higher latency. Its design aims to optimize memory bandwidth and access efficiency in multi-CPU systems, avoiding the performance bottleneck of the memory bus in traditional symmetric multiprocessing systems. It is commonly found in large-scale computing scenarios such as servers and high-performance computing.

[0027] To address the issue of low scheduling and coordination efficiency across resource types caused by CPU, GPU, and memory being managed by different modules in related technologies, this application uses a unified resource pool (computing power pool, memory pool) for aggregated resource management and provides a series of primitives such as pooling initialization, resource allocation, and dynamic adjustment. This integrates resource management operations that were originally scattered across multiple modules into a unified interface at the kernel layer, enabling cross-resource type scheduling to be completed without cross-module collaboration, thus improving coordination efficiency.

[0028] To address the shortcomings of the two-step process of adjusting and destroying old resources and creating new resources, which has a resource vacuum period and cannot guarantee atomicity, this application directly adjusts the number of computing cores or memory block capacity allocated to tasks in real time through dynamic adjustment primitives. This eliminates the resource vacuum period without the need to perform resource destruction and reconstruction processes, ensuring the atomicity of the resource adjustment process and guaranteeing the continuity of business operations.

[0029] To address the issues that existing isolation mechanisms either pose a risk of privilege escape or introduce high performance overhead, this application utilizes resource isolation primitives to achieve isolation of computing core groups or memory blocks for different tasks through hardware mechanisms. This avoids the potential escape risks associated with software-level privilege control and eliminates the need for a virtualization layer, thus avoiding additional performance overhead and achieving a balance between security and performance.

[0030] To address the issue of insufficient adaptation of related technologies to hardware characteristics, which leads to fluctuations in task performance, the resource pool management and primitive operations in this application are designed based on hardware characteristics. For example, they can directly adapt to features such as CPU scheduling domain isolation, GPU SM grouping, and hardware encryption of memory. They can utilize CPU cache allocation technology to achieve cache-level isolation, avoid mutual interference when different tasks share resources, and effectively reduce task performance fluctuations.

[0031] To address the issues of high latency and CPU overhead associated with scheduling relying on user-space components, all resource management operations (pooling initialization, allocation, isolation, adjustment, and reclamation) in this application are implemented through kernel-level primitives, eliminating the need for cross-user-space and kernel-space interaction. This reduces scheduling latency and avoids the additional CPU overhead caused by user-space component scheduling, thereby improving the real-time performance and resource utilization efficiency of resource scheduling.

[0032] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0033] The specific application environment architecture or specific hardware architecture on which the execution of the operating system kernel's resource management methods depends is described here.

[0034] like Figure 1 The diagram shows a schematic of the specific hardware architecture upon which the execution of the operating system kernel's resource management methods depends.

[0035] The hardware architecture includes: processor, memory, hardware components, and hardware abstraction layer.

[0036] The processor includes a CPU and a GPU. The CPU must have affinity configuration capabilities, which can forcibly bind computing cores to target tasks, achieving computing power isolation and exclusive cache access, and avoiding cache pollution caused by cross-core scheduling. The GPU must support hardware-level context isolation and group management, enabling the inclusion of specific computing units into a unified computing power pool for management, and adapting to core-based resource allocation logic. Simultaneously, the processor must provide performance monitoring counters to provide hardware support for resource monitoring primitives to collect metrics such as computing power utilization.

[0037] The memory controller in memory must be compatible with the fine-grained page table permission configuration of the Memory Management Unit (MMU). This can be achieved by setting user-mode / kernel-mode bits and read / write bits in page table entries to bind memory blocks to target tasks and block unauthorized access. Hardware-level memory encryption technology should be supported to encrypt memory blocks for sensitive tasks, ensuring data security without relying on the overhead of software encryption. Furthermore, the memory architecture must support hardware acceleration capabilities for memory block address continuity detection and merging, providing efficiency support for memory fragmentation merging during reclamation and adapting to large-granularity memory allocation requirements.

[0038] The hardware components must have processor features optimized for spinlocks to ensure low-latency execution of atomic operations such as resource pool locking and resource allocation / reclamation, avoiding lock contention overhead in high-concurrency scenarios; support high-precision hardware timers to provide a precise triggering mechanism for resource monitoring primitives and ensure the timeliness of dynamic adjustments.

[0039] The hardware abstraction layer needs to provide standardized kernel-mode hardware access interfaces, supporting direct scheduling of resources such as CPU, GPU, and memory through kernel primitives without relying on user-mode drivers or independent module interfaces, and adapting to the management logic of the kernel-mode unified resource pool. At the same time, it needs to support node-level resource partitioning for non-consistent memory access architectures, be able to build computing power pools and memory pools according to non-consistent memory access nodes, adapt to the needs of pool-level reservation and cross-node resource scheduling, and ensure efficient collaboration of resources on different nodes.

[0040] Embodiments of this application provide a resource management method for an operating system kernel, such as... Figure 2 As shown, the method includes the following steps:

[0041] S201. In response to the request of the target task, execute the resource allocation primitive, determine the target logical resource unit from the initialized resource pool, and allocate the target logical resource unit to the target task.

[0042] The number of target tasks can be one or more. The resource allocation primitive (resource_alloc) is a type of operating system primitive.

[0043] The initialization resource pool is a resource pool of the operating system kernel, including the compute pool (compute_pool_t) and the memory pool (memory_pool_t). The compute pool is used to manage physical computing resources; the memory pool is used to manage physical memory resources.

[0044] The computing power pool has a computing power pool identifier (ID) and a bound server node to reduce latency in cross-node resource calls. The resource list of the computing power pool includes a list of idle core groups and a list of working core groups. Physical computing resources are packaged into computing core groups (core_group_t) as logical computing power units. Each computing core group contains a preset number of computing core carriers (such as CPU cores or GPU SMs), as well as a computing core group identifier, a physical core identifier (such as CPU core number), and linked list nodes.

[0045]

[0046] The control components of the computing power pool have built-in spinlocks, scheduling strategies, and minimum guaranteed computing power.

[0047]

[0048] The memory pool contains a memory pool identifier, the bound server node, the total memory size, and the current free memory size. The memory pool's resource list includes a list of free memory blocks and a list of working memory blocks. Physical memory resources are divided into memory blocks (mem_block_t) as memory resource units. Each memory block contains a preset size, physical address, kernel virtual address for mapping, and memory block identifier (ID), as well as a linked list node.

[0049]

[0050] The memory pool's control component has a built-in spinlock to prevent concurrent operation conflicts.

[0051]

[0052] In some embodiments, before executing step S201, the method further includes: responding to the resource pool creation request from the operating system kernel by executing a pooling initialization primitive to determine whether the request is to create a computing power pool or a memory pool. If the request is to create a computing power pool, the method checks whether the total amount of resources matches the number of processor cores. If so, a computing power pool identifier is generated, and the built-in spinlock of the computing power pool is initialized, as well as a list of idle core groups and a list of working core groups are created. If the request is to create a memory pool, the built-in spinlock of the memory pool is initialized, and a list of free memory blocks and a list of working memory blocks are created.

[0053] The resource pool creation request includes the total amount of resources. The pooling initialization primitive (pool_create) is an operating system primitive, and its pseudocode is shown below:

[0054]

[0055] The function returns an "int" value to indicate the creation result; for example, a return value of 0 indicates success, while a negative value indicates failure and the specific error type. "enumpool_type" is an enumeration type used to specify the specific type of the resource pool. The "pool_type" enumeration predefines supported resource categories, such as a memory pool. "intnode_id" specifies the node to which the resource pool is bound, such as the local node of a NUMA architecture server. "void*resource_range" is a generic pointer pointing to the starting range of the physical or virtual addresses corresponding to the resource pool. "size_tsize" specifies the total size or total number of resources in the pool. "enumsched_policy" is also an enumeration type. "sched_policy" predefines supported scheduling policies (such as first-come, first-served, priority scheduling, fair scheduling, etc.). This parameter specifies the allocation and scheduling rules for resources within the resource pool, ensuring that resources are allocated to requesters according to the preset policy.

[0056] The triggering and execution of the `pool_create` primitive relies on the resource pool management module in the operating system kernel. It supports two triggering methods: First, during the system startup phase, the kernel automatically triggers the creation of a default computing power pool and memory pool for each NUMA node based on the hardware resource scan results (such as the number of CPU cores and memory capacity of each NUMA node). Second, during the system runtime phase, the system administrator submits a resource pool creation request through a system call via command-line tools or applications, specifying the resource pool type (computing power pool / memory pool), the bound NUMA node ID, the total amount of resources, and the scheduling policy (such as priority scheduling), thereby triggering the primitive execution.

[0057] It should be noted that after the operating system powers on and enters the kernel initialization phase, it triggers a resource scanning and abstraction process: First, the hardware resource detection module is started, which collects basic information about physical resources by traversing the system bus and hardware configuration space. For CPU resources, the module reads the number of cores, topology (such as physical core / hyperthread distribution), and NUMA node ID returned by the CPU identification instruction, and identifies the number of stream multiprocessors, compute unit number, and bound NUMA node of the GPU device. For memory resources, the module determines the address range, available capacity, and memory type of physical memory by parsing the memory mapping table provided by the Basic Input / Output System (BIOS), and marks unusable memory areas. For NUMA nodes, the module divides the jurisdiction of different NUMA nodes according to the system hardware topology, records the CPU cores, GPU devices, and local memory address ranges associated with each node, and ensures that local node resources are prioritized during subsequent resource allocation, reducing cross-node access latency.

[0058] Secondly, in the computing resource encapsulation stage, the kernel selects physical computing units from the available CPU cores / GPU SMs of each NUMA node according to the preset core group granularity, based on the principle of consecutive numbering or performance affinity, and generates computing core groups (core_group_t) containing a unique core group ID, the number of physical core groups, a list of physical core IDs, and a linked list of nodes. At the same time, a corresponding computing power pool is created for each NUMA node, the encapsulated idle core groups are added to the list of idle core groups in the computing power pool, and the spin lock, scheduling policy (default priority scheduling), and minimum guaranteed computing power parameters of the computing power pool are initialized. During the memory resource encapsulation stage, the kernel divides the available physical memory of each NUMA node into contiguous memory blocks at a fixed granularity, generating memory blocks (mem_block_t) that contain a unique memory block ID, memory block capacity, physical address, kernel virtual address, and linked list node. Subsequently, a memory pool is created for each NUMA node, free memory blocks are added to the free memory block list, and the total memory size, free memory size statistics, and spinlock of the memory pool are initialized to ensure that available memory blocks can be quickly located and concurrent conflicts can be avoided during subsequent memory allocation.

[0059] The created computing pool and memory pool are associated by NUMA node number and added to the system's global resource pool management list. At the same time, the global configuration of the kernel resource management module is updated so that subsequent operating system primitives (such as the pooling initialization primitive pool_create and the resource allocation primitive resource_alloc) can quickly index the target resource pool through the NUMA node ID or resource pool ID.

[0060] The above embodiments achieve on-demand initialization by determining the request type (computing pool / memory pool), avoiding unnecessary configuration overhead. For the computing pool, initialization is performed on a processor core-by-processor basis, and for the memory pool, on a physical memory block-by-processor basis. This ensures the specificity of the initialization process and avoids management chaos caused by sharing a single architecture between the two types of resource pools, improving initialization efficiency. Secondly, a matching check between the total resource amount and the number of processor cores is added to the computing pool to prevent resource configuration anomalies from the source: if the requested total computing resources exceed the actual number of available processor cores, initialization will terminate, avoiding the contradiction of nominally existing resources being unavailable during subsequent resource allocation, reducing subsequent system anomalies caused by resource configuration errors, and ensuring the availability of the computing pool. Finally, a unified initialization of the built-in spinlock and the idle / working dual-list structure achieves standardization and atomicity guarantees for resource pool management. The initialization of the spinlock ensures the atomicity of subsequent resource allocation, reclamation, and adjustment operations, avoiding resource corruption caused by concurrent conflicts. The separation of the free list and the working list clearly distinguishes the available and occupied states of resources. Subsequent primitives (such as resource_alloc and resource_free) can quickly locate the target resource without traversing all resources. This not only prevents system instability caused by resource contention but also provides efficient data structure support for resource scheduling in high-concurrency scenarios, improving overall resource management efficiency.

[0061] In the above embodiments, when executing the pooling initialization primitive in response to the resource pool creation request from the operating system kernel, it is determined whether the request is to create a computing power pool or a memory pool. The resource pool creation request includes the total amount of resources. If the request is to create a computing power pool, it checks whether the total amount of resources matches the number of processor cores. If so, it generates a computing power pool identifier and initializes the built-in spinlock of the computing power pool, as well as creating a list of idle core groups and a list of working core groups. If the request is to create a memory pool, it checks whether the total amount of resources is within the available memory range of the node. If so, it initializes the built-in spinlock of the memory pool and creates a list of free memory blocks and a list of working memory blocks.

[0062] Specifically, the system first verifies the consistency of resource types and parameters. If a computing pool is being created, it checks whether the total input resource amount matches the physical number of CPU cores / GPU SMs. If a memory pool is being created, it checks whether the total resource amount is within the available memory range of the NUMA node. It also verifies the legality of the scheduling policy, ensuring that the input priority scheduling policy belongs to a preset type supported by the kernel, avoiding illegal policies that could lead to subsequent scheduling anomalies. Furthermore, it checks whether a resource pool of the same type already exists on the target server node. If a conflict exists, execution terminates and an error code is returned; if the verification passes, lock and resource list initialization is performed.

[0063] Then, allocate kernel object memory for the resource pool and generate a unique computing pool identifier, which can adopt the encoding rule of NUMA node ID + resource type + sequence number, such as the first computing pool identifier of node 0 is 0-C-001; for the computing pool, initialize the built-in spin lock, set the lock preemption attribute, and create a list of idle core groups and a list of working core groups. The former is to build an empty linked list through the linked list initialization function, and the core groups after physical resource encapsulation will be connected to it. The latter is initialized as an empty linked list and the linked list node space is reserved; for the memory pool, the spin lock is also initialized, and a list of free memory blocks and a list of working memory blocks are created.

[0064] In addition, the computing power pool also needs to initialize the scheduling policy field and the minimum QoS guaranteed computing power to ensure that the resource pool has basic scheduling and QoS guarantee capabilities.

[0065] The initialized computing pool / memory pool objects are added to the system's global resource pool management list. This list is a doubly linked list maintained by the kernel, which is stored in categories according to resource type (computing pool / memory pool) and NUMA node identifier. During registration, the resource pool node is added to the tail of the corresponding category linked list, and the global resource pool statistics counters (such as the total number of computing pools and the total number of memory pools) are updated.

[0066] After the resource pool is created, it can return a computing pool identifier / memory pool identifier and an execution status code (0 indicates success, non-zero indicates failure) to the requester that triggered the primitive (such as system administrator tools or applications). At this point, the pool_create primitive has completed its entire execution process, and the resource pool enters a ready state that can be called by operating system primitives.

[0067] In some embodiments, when executing the pooling initialization primitive in response to a resource pool creation request from the operating system kernel, the total capacity of the operating system kernel's resource pool is first calculated, including the total number of core groups and the total number of memory blocks. Then, the amount of reserved area resources is calculated based on the total resource pool capacity and a preset ratio corresponding to different task priorities.

[0068] The different task priorities include, but are not limited to, Critical, Elastic, and Best-effort. Critical tasks, such as real-time transactions and industrial control, are characterized by uninterrupted business operations and rigid resource requirements. Elastic tasks, such as data analysis, are characterized by stable business operations but scalable resource requirements. Best-effort tasks, such as log backups, are characterized by no rigid business requirements and no guarantee of resource usage.

[0069] The reserved area resources include the number of computing cores and memory block reserved for different task priorities.

[0070] In the specific implementation of the above embodiments, for the computing power pool, the total number of core groups in the computing power pool is determined by traversing the number of available CPU cores / GPU SMs of the NUMA nodes. For example, if a NUMA node contains 16 CPU cores, then the total number of core groups in the computing power pool is 16. For the memory pool, the total amount of available physical memory is obtained by parsing the memory mapping table. For example, if the available memory of a node is 100GB, then the total capacity of the memory pool is 100GB.

[0071] For example, the number of cores reserved is calculated as the total number of cores × 20%, and the result is rounded up, such as 16 cores × 20% = 3.2 → 4 cores. The memory block reserved capacity is calculated as the total amount of memory blocks × 30%, such as 100GB × 30% = 30GB.

[0072] For the computing power pool, select consecutively numbered core groups from the list of idle core groups, remove these core groups from the general idle list, build a separate critical-level reserved core group list, and record the reserved core group ID, total number of core groups and occupancy status (initially "idle reserved").

[0073] For the memory pool, memory blocks that meet the capacity requirements are selected from the list of free memory blocks to construct a critical-level reserved memory block list, and the reserved memory block ID, total capacity, and encryption status are recorded. Simultaneously, the page table attribute of the reserved memory blocks is marked as "critical-level exclusive." When non-critical tasks initiate memory allocation requests, they will automatically skip the reserved memory blocks and allocate only from the shared area. Furthermore, the `pool_create` primitive also separately records the reserved area resource quantity in the atomic statistics variables of the resource pool, ensuring that the free / occupied status of the reserved area can be read in real time, providing data support for subsequent task-level reservations.

[0074] The above embodiments first calculate the total capacity of the resource pool, transforming underlying hardware resources such as processor cores and physical memory into quantifiable units of core groups and memory blocks that can be uniformly managed by the resource pool. This eliminates the differences between different hardware forms and provides a precise quantitative basis for subsequent resource allocation, reservation, and adjustment, avoiding unfair allocation or insufficient reservation caused by ambiguous resource measurement. This achieves refined and standardized resource pool management, laying a data foundation for tiered protection. Second, the amount of reserved resources is calculated based on the total capacity and a preset ratio. By dividing the total capacity of the resource pool according to task priority, dedicated resource space is pre-locked for high-priority tasks, mitigating the risk of core tasks failing to start or being interrupted due to resources being occupied by low-priority tasks. At the same time, proportional allocation ensures that the amount of reserved resources is compatible with the total system capacity, preventing resource idleness due to excessive reservations and ensuring that core task needs are met due to insufficient reservations, thus achieving a balance between rigid protection and resource utilization. Furthermore, this computational logic possesses exceptional flexibility and scalability. It can be quickly adapted to the resource guarantee requirements of different scenarios by adjusting preset ratios or adding ratios corresponding to new priorities, without requiring the reconstruction of the core logic. This enhances the scenario adaptability and scalability of the QoS mechanism.

[0075] When a Critical task fails to allocate reserved area resources using `resource_alloc`, a logging mechanism is first triggered: detailed exception information is recorded in ` / var / log / kernel / qos_error.log`, including the task PID, QoS registration ID, requested resource amount, current available reserved area resources, and reason for failure. An error code (such as -ENOMEM) is also generated and returned to the task. If the task is a critical service, the kernel will additionally notify the administrator through the system alarm interface, reminding them to promptly expand capacity or adjust resource configuration. Furthermore, the task is added to the QoS allocation waiting queue, and resource allocation is retried every 50ms in blocking mode until sufficient resources are available in the reserved area or the task actively cancels the request, preventing core tasks from terminating due to sudden resource shortages.

[0076] In some embodiments, in response to a Quality of Service (QoS) task registration request, the QoS task registration (qos_register) primitive is executed to determine the task priority identifier and the task resource requirement. Based on the task priority identifier, the reserved area corresponding to the task priority identifier is determined from the resource pool. Then, it is determined whether the remaining resource in the reserved area is greater than or equal to the task requirement. If so, the remaining resource is locked to ensure that the remaining resource is not occupied by any task other than the QoS task.

[0077] The service quality task registration request includes a task priority identifier, task resource requirements, and resource pool association information. The task priority identifier for the service quality task is "Critical"; the task resource requirements are the minimum resource requirements for the service quality task, declaring the minimum quota of computing power and memory. The computing power requirement also specifies the core type, and the memory requirement also indicates whether hardware encryption is enabled; the resource pool association information specifies the computing power pool identifier and memory pool identifier bound to the service quality task.

[0078] Specifically, in response to a service quality task registration request, the validity of the service quality task registration request is first verified. If the parameters are invalid, an error code is returned directly. If the parameters are valid, the reserved areas of the computing power pool and memory pool are checked for margin.

[0079] For the computing power pool in the reserved area, read the list of critical reserved core groups in the computing power pool, count the total number of cores in the available core groups in the list, and compare it with the minimum computing power requirement declared by the task. If the task requires 4 cores, and there are 2 core groups with 2 cores in the reserved area, it is considered sufficient. At the same time, check whether the type of core group in the reserved area matches the task requirements. If the task requires GPU computing power, only the GPUSM core group is checked.

[0080] For the memory pool in the reserved area, traverse the list of critical reserved memory blocks, and merge multiple consecutive free memory blocks into a large memory block that meets the requirements using a memory block merging algorithm. Then calculate the total available capacity of the reserved area and compare it with the minimum memory requirement of the task. If hardware encryption is required, additionally check whether the memory block supports encryption features.

[0081] If all resource pools have sufficient reserves, a locking operation is performed on the reserved area resources. For the computing power pool, computing core groups that meet the requirements are selected from the list of critical-level reserved core groups, the status of the computing core groups is marked as reserved (unallocated), and the identifier of the computing core group and the associated task process identifier (PID) are recorded to prevent other tasks from occupying them; for the memory pool, memory blocks that meet the requirements are similarly selected and marked, hardware encryption configuration is enabled synchronously, and the memory block ID and task PID are recorded. The QoS registration ID and success status code (0) are returned to the task, and the qos_monitor primitive initialization is triggered to create a periodic resource monitoring thread for the QoS task, completing the entire QoS task registration process. If the reserves of any resource pool are insufficient, an error code is returned to the QoS task, terminating the task registration process.

[0082] The above embodiments first achieve precise binding between priority and resource pool by determining task priority identifiers and matching them with corresponding reserved areas. Tasks of different priorities are directed to dedicated reserved areas (e.g., Critical tasks are matched with QoS-dedicated reserved areas), preventing low-priority tasks from occupying high-priority reserved resources. This establishes the boundary of hierarchical resource protection from the source, ensuring that the resource needs of high-priority tasks are not interfered with. Second, the matching between the remaining resources in the reserved area and the task's demand is judged. Task registration is only allowed when the reserved area resources are sufficient, directly rejecting the creation of QoS tasks in scenarios with insufficient resources. This avoids interruption or degradation of task operation due to resource gaps, ensuring the certainty of the basic resource conditions for QoS task operation. Finally, by locking the matched remaining resources and restricting their use to only that task, the locking operation, through kernel-mode permission control and resource pool status marking, blocks other tasks (including non-target tasks of the same priority) from accessing this part of the resources. This ensures that the minimum resource requirements of QoS tasks are not encroached upon, laying a stable resource foundation for subsequent resource allocation, dynamic adjustment, and other processes.

[0083] Based on the above embodiments, when executing step S201, in response to the resource allocation request of the target task, a resource allocation primitive is executed to determine the task resource requirements of the target task. If the task resource requirements of the target task point to the computing power pool, a spinlock is added to the computing power pool, and a computing core group is determined from the list of idle core groups in the computing power pool and allocated to the target task; if the task resource requirements of the target task point to the memory pool, a spinlock is added to the memory pool, and a memory block is determined from the list of idle memory blocks in the memory pool and allocated to the target task.

[0084] The resource allocation primitive is the core entry point for the target task to acquire logical resources, supporting initial allocation during task creation and scaling requirements during task runtime. The pseudocode is shown below:

[0085]

[0086] Here, `compute_pool_id` is a unique identifier for the computing resource pool, used to specify which pre-created computing resource pool to allocate computing resources from. `memory_pool_id` is a unique identifier for the memory resource pool, corresponding to the source pool for memory allocation. `intcore_count` represents the required number of computing cores. `size_tmem_size` represents the required memory capacity. `boolqos_guarantee` is a boolean QoS guarantee flag; a value of `true` indicates that QoS guarantees are required for this resource allocation, while `false` indicates that no mandatory guarantee is required, and the allocation is handled according to normal allocation logic. `enumalloc_mode` is an enumerated type of allocation mode. `alloc_mode` predefines supported modes, such as immediate allocation and blocking wait. Immediate allocation means that if there are insufficient resources, it will return failure directly, while blocking wait means that if there are insufficient resources, the requesting process will wait until sufficient resources are available before completing the allocation. `int*core_group_id` and `int*mem_block_id` are pointer-type output parameters used to store the result after successful allocation. `core_group_id` points to the unique identifier of the allocated computing core group, and `mem_block_id` points to the unique identifier of the allocated memory block. If the allocation fails, both parameters will return -1.

[0087] Specifically, the core parameters of the target task are first passed to the resource allocation primitive, including the target computing pool identifier, the target memory pool identifier, the task resource requirements, and may also include the QoS guarantee identifier and allocation mode. The allocation mode includes immediate allocation and blocking wait. The system checks whether the target computing pool identifier or the target memory pool identifier exists in the global resource pool hash table; verifies whether the task resource requirements conform to the resource pool granularity, such as whether the computing power requirement is an integer multiple of the computing core group or the memory requirement is an integer multiple of the memory block; and confirms whether the allocation mode is the preset type. If the above core parameters are valid, a spinlock is added to the target computing pool, and a computing core group is determined from the list of idle core groups in the computing pool and allocated to the target task. A spinlock is added to the target memory pool, and a memory block is determined from the list of idle memory blocks in the memory pool and allocated to the target task.

[0088] The above embodiments first determine the resource requirement type (computing power / memory) of the target task to achieve on-demand targeted allocation. Computing power requirements are directly matched to the computing power pool, and memory requirements are matched to the memory pool, avoiding invalid searches across resource types, making resource allocation more targeted, reducing redundant operations in the allocation process, and improving response speed. Secondly, the design of adding a spinlock to the corresponding resource pool before allocation is crucial for ensuring atomicity and concurrency safety. The spinlock can quickly lock the resource pool, preventing resource contention and duplicate allocation when multiple tasks simultaneously request the same resource pool. Furthermore, in short-operation scenarios, the spinlock does not require thread switching, resulting in lower overhead compared to mutex locks, ensuring the stability and low latency of resource allocation in high-concurrency scenarios. Finally, the allocated resources are directly determined from the idle list (idle core group list / idle memory block list) of the resource pool. Relying on the list structure that separates idle and working resources, available resources can be quickly located without traversing the entire resource pool, improving resource retrieval efficiency, making the allocation process simpler and more efficient, and providing support for rapid task startup.

[0089] Based on the above embodiments, if the target task is a critical task (such as a QoS task), the critical-level reserved core group number and critical-level memory block capacity that meet the requirements of the critical task are first selected from the critical-level reserved area of ​​the resource pool; if the critical-level reserved core group number in the critical-level reserved area does not meet the requirements of the critical task, the target computing core group number is preempted from the shared area of ​​the resource pool. The target computing core group number is the number of computing core groups reclaimed from tasks with a task priority lower than the critical level; the critical-level reserved core group number, the target computing core group number, and the critical-level memory block capacity are allocated to the target task.

[0090] When allocating computing core groups, differentiated allocation logic can be executed based on task priority: For Critical-level tasks, the list of reserved core groups is traversed first to select core groups that meet the requirements. For example, if a task requires 4 cores, one 4-core core group or two 2-core core groups are matched. If the reserved area is sufficient, the core group is directly moved from the reserved area to the working core group list, and the core group ID is recorded. If the reserved area is insufficient, the excess resources of low-priority tasks are preempted from the shared area, such as core groups exceeding the minimum requirements for Elastic-level tasks and all core groups for BestEffort-level tasks. The allocation is completed after the resources are forcibly reclaimed through the qos_preempt sub-logic. The role of the qos_preempt sub-logic is to trigger the preemption mechanism when high-priority tasks / services need resources but system resources are insufficient. That is, to suspend or degrade the resource occupation of low-priority tasks, and to prioritize the allocation of released resources (such as CPU computing power, memory bandwidth, network bandwidth, etc.) to high-priority tasks, ensuring that the QoS indicators such as latency and jitter of high-priority tasks meet the standards.

[0091] For Elastic-level tasks, resources are allocated only from the shared core group list. If the shared area is insufficient and the allocation mode is blocking wait, the task is added to the computing power waiting queue and awakened by the resource_free primitive when resources are released. If allocation is immediate, an error code (-EAGAIN) is returned. For BestEffort-level tasks, only the remaining free resources in the shared area and reserved area can be used, and registered QoS reserved resources are not allowed to be occupied. If allocation fails, an error code (-ENOENT) is returned directly.

[0092] When allocating memory blocks, Critical-level tasks prioritize allocation from the critical-level reserved memory block list, supporting the merging of contiguous free memory blocks to meet requirements; Elastic and BestEffort-level tasks allocate from the shared area and remaining free area respectively, and tasks in blocking wait mode enter the memory waiting queue. If memory allocation is successful, the memory block is moved from the free list to the allocated list, the memory pool's free_size is updated, and the spinlock is released; if allocation fails, a failure rollback mechanism is triggered.

[0093] If memory allocation fails but computing power has already been allocated, the kernel will immediately relock the computing power pool, move the allocated core groups from the working core group list back to the original list (core groups for critical tasks are moved back to the reserved area, and core groups for other tasks are moved back to the shared area), update the computing power pool idle resource statistics, and wake up the highest priority task in the computing power waiting queue. After the rollback is complete, all spinlocks are released, and an error code (-ENOMEM) is returned to the task. If both computing power and memory are allocated successfully, the kernel records the allocated computing core group identifier and memory block identifier, triggers the resource isolation primitive initialization, binds resources to the task and sets isolation permissions, and finally returns a success status code (0) and resource ID to the task. At this point, the resource_alloc primitive completes the resource allocation process, the task can start execution based on the allocated computing power and memory, and the resource guarantee corresponding to the QoS priority has taken effect.

[0094] First, the reserved area serves as a dedicated resource pool for critical tasks, pre-locking stable computing and memory resources. This prevents critical tasks from competing with other priority tasks for general resources, ensuring that critical tasks can quickly obtain the necessary cores and memory blocks when system resources are not saturated, guaranteeing low-latency startup and operation. Second, when resources in the reserved area are insufficient, a mechanism is triggered to preempt resources from lower-priority tasks in the shared area. By forcibly reclaiming excess resources from tasks with priorities lower than critical, even when system resources are strained, resource reallocation can meet the needs of critical tasks, ensuring availability in extreme scenarios and preventing critical business interruptions due to resource shortages, thus safeguarding the bottom line of core service operation. Furthermore, the preemption logic explicitly limits the reclamation of resources to low-priority tasks, with the preemption cap set to meet the needs of critical tasks. This avoids infringing on the minimum resource guarantees for low-priority tasks (such as the basic resources of Elastic tasks) while preventing excessive preemption that could lead to system resource imbalance, ensuring the protection of critical tasks while minimizing the impact on other tasks.

[0095] When the `qos_preempt` sub-logic preempts a low-priority task resource, a preemption conflict will be triggered if the target task is performing a critical operation. In this case, the kernel does not forcibly interrupt the task but instead executes a delayed preemption strategy: first, it records the conflict information (such as the task PID, the target resource ID, and the reason for the conflict) to the log; then, it sets a delay timer, and after the timer expires, it re-checks the target task's status. If the task has released the critical resource, preemption is performed immediately; if it is still in a conflict state, the delay process is repeated. If the conflict is still not resolved after retrying, the kernel will forcibly pause the target task, perform resource preemption, and add the target task to the resource recovery queue. When system resources are sufficient, the `resource_adjust` primitive is called to restore its resource configuration and execution state, balancing QoS task guarantees and fairness for low-priority tasks.

[0096] S202. Execute the resource isolation primitive to isolate the target logical resource unit from the logical units corresponding to other tasks through hardware isolation mechanisms.

[0097] The resource isolation primitive (resource_isolate) is triggered only before the task is first selected by the scheduler, without requiring the task to initiate it. The pseudocode is shown below:

[0098]

[0099] Other tasks are any one or more tasks other than the target task.

[0100] In some embodiments, resource isolation primitives are executed to bind the computing core group in the target logical resource unit to the target task and disable the preemption function of the computing core group; or, the memory block in the target logical resource unit is bound to the target task and the memory block is encrypted.

[0101] Specifically, in the computational power isolation stage, the kernel first extracts the core group identifier and queries the physical resource information corresponding to the core group (such as CPU core number, GPU SM number, and the NUMA node to which it belongs). Then, it performs binding operations for CPU and GPU resources. For CPU computational power isolation, the kernel uses the CPU affinity mechanism to forcibly bind the task PID to the physical core within the core group. By modifying the kernel scheduling domain configuration, these cores are removed from the system's common scheduling domain, allowing only the current task's thread to be scheduled within the core group. At the same time, the kernel disables core preemption to prevent high-priority tasks from being preempted by low-priority tasks, or cache pollution caused by threads of different tasks switching on the same core. For GPU computational power isolation, the kernel sends context configuration instructions to the GPU device through the GPU driver, binding the SM unit within the core group to the task's GPU context. The SM's instruction execution priority is set to the highest, ensuring that the GPU hardware prioritizes scheduling the task's computation instructions, while blocking access requests from other tasks to the bound SM unit.

[0102] In the memory isolation phase, the kernel first reads the corresponding memory block identifier from the target task control block, obtains the physical address range and virtual address mapping information of the memory block, creates an independent page table space for the target task, and configures the access permissions of the page table entries through the memory management unit: only the process context corresponding to the current target task PID is allowed to have read / write permissions, and other tasks can only read the page table entries but cannot modify or access physical memory. The permission configuration is achieved by modifying the permission bits of the page table entries.

[0103] Secondly, if memory encryption is declared during task registration, the kernel triggers a hardware encryption process: For platforms supporting Intel Software Protect Extensions, the Software Protect Extensions driver is invoked to mark the target memory block as an encrypted area, and a dedicated encryption key is generated through the Software Protect Extensions encryption engine; for platforms supporting AMD's secure encrypted virtualization technology, memory encryption is similarly enabled and bound to the task's encryption context, ensuring that data in the memory block can only be decrypted and read by the current task, and other tasks, even if they obtain the physical address, cannot parse the data content. Furthermore, the kernel also uses the memory controller's address filtering function to add the task's memory block physical address to the allowed access list, rejecting memory access requests from unauthorized tasks.

[0104] The above embodiments first bind the computing core group to the target task and disable preemption. Through hardware-level binding (such as CPU affinity configuration), it is ensured that the computing core group serves only the target task. Disabling preemption prevents other tasks from temporarily occupying the core group, reducing context switching and cache pollution, and allowing the target task to obtain stable computing performance. Second, memory blocks are bound to the target task and encrypted. The binding operation is configured through the page table permissions of the memory management unit, allowing only the target task to access the memory block, preventing data from being read or tampered with illegally. The encryption function further strengthens the protection of sensitive data, ensuring data security and privacy, and preventing cross-task data leakage. In addition, whether it is computing power binding or memory binding, it is essentially to block resource interference between tasks at the hardware and kernel level, avoiding performance fluctuations caused by different tasks sharing resources (such as computing power contention caused by shared core groups, and access conflicts caused by shared memory), so that the target task does not interfere with other tasks, ensuring the operational reliability of the target task and reducing the risk of overall system failure propagation.

[0105] S203. Run the target task based on the target logical resource unit.

[0106] Once the target task (such as a QoS task) is registered, a timer is created. When the timer expires, it will trigger the execution of the resource monitoring (qos_monitor) primitive.

[0107] In some embodiments, during the execution of the target task, resource monitoring primitives are executed to collect resource metrics during the target task's execution. These metrics include at least one of computing power utilization, memory utilization, memory page fault rate, and memory access latency. When a resource metric does not meet a preset threshold, a resource adjustment request is triggered to execute a dynamic adjustment primitive. The resource adjustment request includes the target task's current resource usage and target resource usage. If the target resource usage is greater than the current resource usage, new logical resource units are determined from the initialization resource pool and allocated to the target task. If the target resource usage is less than the current resource usage, a portion of the logical resource units corresponding to the target task is determined based on the target and current resource usages. The resource quantity of these partial logical resource units is greater than or equal to the target task's task requirement. These partial logical resource units are then released back to the initialization resource pool.

[0108] When the qos_monitor primitive is executed, it first filters out all QoS tasks and collects core resource metrics one by one according to the task PID: For computing resources, it reads the performance monitoring counters of CPU / GPU (such as CPU's perf_event and GPU's SM utilization register) and calculates the computing utilization rate within the past preset time period (500ms) = core occupancy time / total monitoring time; For memory resources, it obtains the task's memory utilization rate = used memory / allocated memory, page fault rate (i.e., page faults per second) and memory access latency (read through the memory controller's latency register) through the memory management subsystem.

[0109] Then, the real-time data is compared with preset thresholds. For example, if the computing power utilization of a Critical / Elastic task exceeds 90% for 500ms, it is determined to be insufficient computing power; if the memory page fault rate exceeds 10 times / second or the memory utilization exceeds 85%, it is determined to be insufficient memory; if the computing power utilization is below 30% for 1 second or the memory utilization is below 20%, it is determined to be excessive resources. If the indicators do not exceed the thresholds, the primitive only updates the monitoring statistics of the resource pool and resets the timer to wait for the next trigger.

[0110] When a resource shortage or resource surplus condition is triggered, the qos_monitor primitive generates a resource adjustment request, which includes the task PID, the current resource usage, and the target adjustment amount (e.g., requesting to expand by 2 cores when computing power is insufficient, and requesting to shrink by 1 core when resources are surplus). The request is then sent to the request queue of the dynamic resource adjustment (resource_adjust) primitive through the kernel message queue.

[0111] The pseudocode for the dynamic resource adjustment primitive is shown below:

[0112]

[0113] When the dynamic resource adjustment primitive is executed, it first extracts the task PID, the number of new computing cores, and the new memory size from the adjustment request. Then, it calls the non-blocking mode of the `resource_alloc` primitive to request new resources from the computing / memory pool bound to the task. If it's an expansion, it prioritizes allocation from the free area of ​​the resource pool, with critical-level tasks having priority to use reserved free resources. If it's a reduction, it needs to be confirmed that the target resource amount is not less than the task's minimum requirement. After successful pre-allocation, it obtains the new core group ID and memory block ID. If pre-allocation fails, and there are no free resources in the resource pool, it returns an error code (-ENOMEM) and notifies the `qos_monitor` primitive to trigger the subsequent preemption process, pausing the current adjustment.

[0114] Next, a mutex lock is added to the task to prevent other threads from modifying the task resource configuration simultaneously. Then, the `task_resources` field of the task control block is updated directly, replacing the old core group ID and old memory block ID with the new resource ID, and the task's resource requirement record is updated synchronously. For computing resources, the task thread also needs to be bound to the new core group, and the GPU SM unit binding relationship needs to be updated. For memory resources, the virtual address mapping is re-established to ensure that the task can access the new memory block, while retaining the data in the old memory block. The old memory data can be migrated to the new memory block, and task scheduling is disabled during the migration process to avoid data inconsistency. After the update is complete, the task mutex lock is unlocked to ensure that the task can access the new resources normally.

[0115] The `resource_free` primitive is called, passing in the old core group ID and the old memory block ID, to execute the reclamation logic according to resource type. Computation core groups are moved from the working core group list back to the free core group list, and old core groups of critical-level tasks are preferentially released back to the reserved area; memory blocks are moved back to the free memory block list, and adjacent blocks are merged to reduce fragmentation.

[0116] During the recycling process, the primitive checks whether the old resource is associated with other tasks (such as in a shared resource scenario). If only the current task occupies it, it is recycled directly; if it is shared, only the binding relationship of the current task is removed. After recycling is complete, the primitive updates the idle resource statistics of the resource pool and returns a successful adjustment status code (0) to the task, while resetting the task_qos_status field (marking "adjustment complete"). In the case of a scaling-down scenario, the primitive qos_monitor will also be notified to update the monitoring baseline value.

[0117] When the target task lacks sufficient resources, the `qos_monitor` primitive triggers the `resource_adjust` primitive to preempt excess resources without infringing on the basic guarantees of lower-priority tasks. First, it iterates through all task-bound compute / memory pools, filtering out preemptible lower-priority tasks. For Elastic-level tasks, only resources exceeding the minimum requirement are preempted; for example, if an Elastic task requires at least 2 cores but occupies 6, 4 cores can be preempted. For BestEffort-level tasks, since there are no basic resource guarantees, all their occupied resources can be preempted. During the filtering process, tasks holding kernel locks are identified and skipped if they are performing critical operations, preventing deadlocks caused by preemption.

[0118] After filtering, a reduction request is generated for each task, forcibly adjusting the resource allocation of Elastic-level tasks to the minimum requirement and reducing the resource allocation of BestEffort-level tasks to 0. During forced adjustment, the task context (such as CPU register state, GPU computing context, and memory data snapshot) is first saved and stored in the kernel temporary cache; then, the task is unbound from the old resources, and the old resources are marked as "pending allocation." If the target task refuses adjustment (e.g., returning an error code), it will retry after a 100ms delay. If it still fails after 3 retries, the task is forcibly paused, and execution will resume after resource reclamation, ensuring that the preemption process is not blocked.

[0119] The reclaimed compute cores and memory blocks are aggregated and directly allocated to the critical-level tasks awaiting adjustment by calling the "priority mode" of the resource_alloc primitive. Computational resources are prioritized for allocation to contiguous cores to reduce scheduling overhead, and memory resources are prioritized for allocation to memory blocks with encryption enabled.

[0120] After allocation, the sub-logic updates the QoS statistics of the resource pool (such as qos_used_cores and qos_used_blocks) and returns a preemption success notification to the qos_monitor primitive. The qos_monitor then resets the task's monitoring thresholds based on the newly allocated resource amount. For preempted Elastic / BestEffort tasks, the sub-logic automatically calls the resource_adjust primitive to restore their original resource configuration when idle resources become available in the resource pool. This ensures the elastic operation of low-priority tasks and balances system fairness with resource guarantees for critical tasks.

[0121] The above embodiments first collect core indicators such as computing power utilization and memory usage through resource monitoring primitives. These indicators reflect the balance of task resource supply and demand, accurately capturing resource supply and demand deviations, providing data support for dynamic adjustments, and avoiding blind expansion or contraction. Second, preset thresholds are used as adjustment trigger conditions, achieving standardization and automation of adjustment timing. The thresholds can be flexibly configured according to task type, and adjustments are automatically triggered when indicators exceed the thresholds, without manual intervention, quickly adapting to task load fluctuations. Finally, the dynamic adjustment primitives execute operations according to the logic of expanding to supplement resources and contracting to release resources: during expansion, new logical resource units are added from the resource pool to ensure that tasks have sufficient resources to support performance requirements; during contraction, resources exceeding the target usage are released (while retaining no less than the minimum resource requirement of the task), avoiding resource idleness and waste. This ensures that tasks are not degraded due to insufficient resources during peak loads, and releases redundant resources for other tasks during off-peak loads, achieving on-demand allocation and dynamic flow.

[0122] When the hardware detects that resources used by a QoS task are corrupted, the memory controller and CPU monitoring module send a hardware interrupt signal to the kernel, triggering the resource corruption handling process. The kernel first locates the corrupted resource using the interrupt handler: it reads the CPU fault register to determine the faulty core ID, or it determines the physical address of the corrupted memory block through the memory controller log, thus associating it with the corresponding QoS task and resource pool. Then, it performs resource isolation: in the computing power pool, the core group containing the faulty core is marked as "unavailable," and it is removed from the critical-level reserved core group list and the idle core group list to prevent other tasks from allocating it; similarly, in the memory pool, the corrupted memory block is marked as "unavailable," the corrupted capacity is deducted, and the page table of the memory block is set to inaccessible to prevent system crashes caused by task access. Simultaneously, the kernel records corruption information to the hardware fault log (e.g., / var / log / kernel / hw_error.log), including the type of corrupted resource (CPU / GPU / memory), resource ID, associated QoS task PID, and fault time. It also notifies the qos_monitor primitive to trigger emergency resource adjustments, reallocating available resources (from the reserved area or shared area) to affected critical tasks. The resource_adjust primitive migrates task data and context to the new resources, ensuring uninterrupted task operation. Finally, the kernel synchronizes the corrupted resource information to the system hardware management module, allowing administrators to perform subsequent hardware repair or replacement, completing the closed-loop handling of the anomaly.

[0123] S204. When the target task terminates, execute the resource reclamation primitive to release the target logical resource unit back to the initialization resource pool.

[0124] Upon detecting a task exit signal, the `resource_free` primitive is executed to reclaim the computing cores and memory blocks occupied by the target task and return them to their corresponding resource locations. The pseudocode is shown below:

[0125]

[0126] In some embodiments, a resource reclamation primitive is executed when the target task terminates. First, a spinlock is added to the computing pool to ensure atomicity; then, the computing cores already allocated to the target task are moved from the working core list back to the free core list. Alternatively, a spinlock is added to the memory pool, and the memory blocks already allocated to the target task are moved from the working memory block list back to the free memory block list.

[0127] Specifically, the allocated core group ID is first extracted and combined with the computing pool ID bound to the task. The target computing pool is then quickly located using the global resource pool hash table. The kernel adds a spinlock to the computing pool and disables local interrupts to ensure atomicity. The working core group list of the computing pool is traversed to find the core group node that matches the target core group ID. If the task is Critical level, it is necessary to first check whether the core group belongs to the critical-level reserved area. If so, the core group status is reset from "allocated" to "reserved area idle" and moved back to the computing pool's "critical-level reserved core group list," while increasing the corresponding core group count. If the core group is a non-QoS core group occupied by an Elastic / BestEffort task, the core group is moved to the idle core group list, and the task PID flag associated with the core group is cleared.

[0128] After the core group movement is complete, for CPU core groups, the affinity configuration between tasks and physical cores is cleared, the cores are re-integrated into the system's common scheduling domain, and the core preemption function is restored. For GPU core groups, a context reset command is sent via the GPU driver to unbind the SM unit from the original task, clear the SM's priority configuration, and return the SM unit to the "idle and schedulable" state. Finally, the computing power pool spinlock is released, the idle core group count in the computing power pool is updated (increasing the number of reclaimed core groups), and the highest priority task in the computing power waiting queue is woken up and notified that new idle resources are available.

[0129] Next, extract the task's memory block ID and the bound memory pool ID, locate the target memory pool, and add a spinlock. First, traverse the list of working memory blocks, find the target memory block, and perform a state reset: if the memory block has hardware encryption enabled, first disable the encryption function through the memory controller, release the encryption key, and then mark the memory block status as "free"; if it is a normal memory block, directly clear the "allocated / working" mark and the associated task PID.

[0130] The above embodiments add spinlocks to the corresponding resource pools (computing pool / memory pool) before recycling to ensure the atomicity and concurrency safety of the recycling operation. Spinlocks can quickly lock the resource pool, preventing resource state disorder caused by other tasks simultaneously requesting the same resource pool during the target task's resource recycling process. Moreover, spinlocks do not require thread switching in short operation scenarios, resulting in lower performance overhead compared to mutexes. This avoids concurrency conflicts while controlling performance costs, ensuring the stability of resource recycling in high-concurrency scenarios. Secondly, the allocated computing cores / memory blocks are moved from the working list back to the free list, enabling resource reuse. By updating the list state of the resource pool, the recycled resources are made eligible for reassignment, preventing resources from remaining idle for a long time after task termination, improving system resource utilization, and ensuring that limited computing power and memory resources can be continuously used by subsequent tasks. Furthermore, relying on the list structure that separates work and idle resources, the reclaimed resources are directly added to the idle list. Subsequent resource allocation primitives can directly retrieve available resources from this list without additional processing of resource state transitions, thus maintaining the high efficiency of resource allocation, upholding the standardized process of resource pool management, and forming a closed loop of resource "allocation-reclaim-reallocation", thereby improving the overall resource scheduling efficiency.

[0131] In some embodiments, after adding a spinlock to the memory pool and moving the memory blocks already allocated to the target task from the working memory block list back to the free memory block list, if the target memory block has a contiguous address with an adjacent memory block in the free memory block list, a memory block merging operation is performed to merge the target task's memory block with the adjacent memory block.

[0132] The memory block merging operation specifically includes: checking whether the preceding and following nodes of the current memory block are both in a "free" state; if the preceding node is free and the physical addresses are contiguous, i.e., the physical address of the current block = the physical address of the preceding block + the size of the preceding block, then merging them into one large memory block, updating the size and physical address of the merged memory block, and deleting the original preceding block node; similarly, checking and merging subsequent free blocks to ensure that the reclaimed memory blocks exist in a large granularity as much as possible, reducing the fragmentation splicing overhead during subsequent allocation.

[0133] After merging, the processed memory blocks can be moved to the free memory block list. Simultaneously, the access permission configuration of the memory blocks is cleared, and the address mapping between the target task and the memory blocks is removed. If there is unsynchronized memory data before task termination (such as dirty data in the cache), the cached data is written to the memory blocks before recycling to avoid data residue. After releasing the memory pool spinlock, the memory waiting queue is woken up, notifying the waiting tasks that the memory resources have been released.

[0134] Finally, the resource ID record is cleared in the task control block, and the resource occupancy flag is reset to ensure that no resources are associated when the task exits. At this point, the resource_free primitive has completed its entire execution process, and the computing power and memory resources occupied by the task are completely returned to the resource pool, achieving resource recycling and providing sufficient free resources for subsequent task scheduling.

[0135] In the above embodiments, after memory blocks are reclaimed to the free list, their address continuity with adjacent memory blocks is specifically detected to accurately locate mergeable fragmented resources, providing targeted targets for subsequent merging operations. Secondly, memory blocks with contiguous addresses are merged into larger memory blocks, achieving fragment consolidation and resource expansion. The merged larger memory blocks can adapt to the memory requirements of more types of tasks, avoiding resource waste due to insufficient total memory but inability to allocate large memory blocks caused by excessive fragmentation, improving memory resource availability, and broadening the applicable scenarios for free memory. Furthermore, the merged large memory blocks are still included in the free memory block list, and subsequent resource allocation primitives can directly retrieve and use them without additional fragmentation concatenation, optimizing subsequent allocation efficiency, reducing the overhead of memory block matching and concatenation during allocation, and shortening the response time for task memory requests.

[0136] In some embodiments, after a critical task terminates, the qos_release primitive is executed to release the resources occupied by the critical task back to the corresponding resource pool, ensuring that the resources in the critical reserved area can be reused by other critical tasks.

[0137] First, extract key information from the task control block, including: QoS registration ID, bound computing pool / memory pool ID, locked reserved core group ID / memory block ID, and dynamically allocated non-reserved resource ID, such as the core group obtained by preempting Elastic tasks.

[0138] For critical-level reserved resources, for the computing pool, `qos_release` confirms the status of reserved core groups, moves core groups marked "locked reserved" from the working core group list back to the critical-level reserved core group list, resets the core group status to "idle reserved," and deletes the associated record of the task PID; simultaneously, it unbinds the CPU / GPU hardware, restoring the core group to a state where it can be allocated by new critical tasks. For the memory pool, the primitive moves "locked reserved" memory blocks from the working memory block list back to the critical-level reserved memory block list. If the memory block has hardware encryption enabled, it first disables the encryption function, destroys the key, then resets the memory block access permissions, and increases the released memory capacity.

[0139] For dynamically allocated non-reserved resources, such as Elastic task resources preempted from the shared area, the `qos_release` primitive calls the `resource_free` sub-logic to release these resources back to the general free area: compute core groups are moved to the free core group list, memory blocks are merged and moved to the free memory block list, and tasks in the corresponding waiting queues are woken up. Finally, the `qos_release` primitive clears the QoS-related flags in the task control block, updates the QoS statistics of the resource pool, and sends a resource release notification to the `qos_monitor` primitive. The monitoring module then updates the global QoS resource view, completing the entire release process.

[0140] In summary, the resource management method for an operating system kernel provided in this application aggregates and manages resources through a unified resource pool (computing pool, memory pool), and provides a series of primitives such as pooling initialization, resource allocation, and dynamic adjustment. This integrates resource management operations, originally scattered across multiple modules, into a unified interface at the kernel layer, enabling cross-resource type scheduling without cross-module collaboration, thus improving coordination efficiency. Furthermore, the dynamic adjustment primitive directly adjusts the number of computing cores or memory block capacity allocated to tasks in real time, eliminating resource destruction and reconstruction processes, thus preventing resource vacuum periods and ensuring the smooth operation of resource adjustment. Atomicity ensures the continuity of business operations; resource isolation primitives rely on hardware mechanisms to isolate computing core groups or memory blocks for different tasks, which avoids the escape risks that may exist in software-level access control, and does not require reliance on the virtualization layer, avoiding additional performance overhead and achieving a balance between security and performance; resource management operations (pooling initialization, allocation, isolation, adjustment, and reclamation) are all implemented through kernel-level primitives, without the need for interaction between user space and kernel space, shortening scheduling latency, and avoiding the additional CPU overhead caused by user space component scheduling, thereby improving the real-time performance of resource scheduling and resource utilization efficiency.

[0141] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0142] like Figure 3 As shown, embodiments of this application also provide a resource management device for an operating system kernel, the device comprising:

[0143] Resource allocation module 301 is used to execute resource allocation primitives in response to the request of the target task, determine the target logical resource unit from the initialization resource pool, and allocate the target logical resource unit to the target task; the initialization resource pool is the resource pool of the operating system kernel, including the computing power pool and the memory pool; the target logical resource unit includes computing core groups or memory blocks;

[0144] Resource isolation module 302 is used to execute resource isolation primitives to isolate the target logical resource unit from the logical resource units corresponding to other tasks through hardware isolation mechanisms; other tasks are any tasks other than the target task.

[0145] Task execution module 303 is used to run target tasks based on target logical resource units;

[0146] The resource reclamation module 304 is used to execute the resource reclamation primitive when the target task terminates, and release the target logical resource unit back to the initialization resource pool.

[0147] As an optional implementation provided in this application embodiment, the device further includes a pooling initialization module, used to: execute pooling initialization primitives in response to a resource pool creation request from the operating system kernel, and determine whether the request is to create a computing power pool or a memory pool; the resource pool creation request includes the total amount of resources; if the request is to create a computing power pool, check whether the total amount of resources matches the number of processor cores, and if so, generate a computing power pool identifier and initialize the spinlock built into the computing power pool, and create a list of idle core groups and a list of working core groups; if the request is to create a memory pool, initialize the spinlock built into the memory pool, and create a list of free memory blocks and a list of working memory blocks.

[0148] As an optional implementation provided in this application embodiment, the resource allocation module 301 is specifically used for: responding to the request of the target task by executing a resource allocation primitive to determine the task resource requirements of the target task; if the task resource requirements point to the computing power pool, then add a spinlock to the computing power pool, and determine the computing core group that meets the task resource requirements from the list of idle core groups in the computing power pool, and allocate it to the target task; if the task resource requirements point to the memory pool, then add a spinlock to the memory pool, and determine the memory block that meets the task resource requirements from the list of idle memory blocks in the memory pool, and allocate it to the target task.

[0149] As an optional implementation provided in this application, the resource isolation module 302 is specifically used to: execute resource isolation primitives to bind the computing core group in the target logical resource unit to the target task and disable the preemption function of the computing core group; or, bind the memory block in the target logical resource unit to the target task and encrypt the memory block.

[0150] As an optional implementation provided in this application, the device further includes a pooling initialization module, used to: execute pooling initialization primitives in response to a resource pool creation request from the operating system kernel, calculate the total capacity of the operating system kernel's resource pool, including the total number of core groups and the total number of memory blocks; calculate the amount of reserved area resources based on a preset ratio corresponding to the total capacity of the resource pool and different task priorities; the reserved area resources include the number of reserved core groups and the reserved capacity of memory blocks corresponding to different task priorities.

[0151] As an optional implementation provided in this application, the device further includes a service quality task registration module, used to: execute a service quality task registration primitive in response to a service quality task registration request, determine a task priority identifier and a task resource requirement; determine a reserved area corresponding to the task priority identifier from the resource pool based on the task priority identifier; determine whether the resource balance in the reserved area is greater than or equal to the task resource requirement; if so, perform a locking operation on the resource balance to ensure that the resource balance is not occupied by tasks other than service quality tasks.

[0152] As an optional implementation provided in this application, the resource allocation module 301 is specifically used for: when the target task is a critical task, selecting the number of critical-level reserved core groups and the capacity of critical-level memory blocks from the critical-level reserved area of ​​the resource pool to meet the requirements of the critical task; if the number of critical-level reserved core groups in the critical-level reserved area does not meet the requirements of the critical task, then preempting the target number of computing core groups from the shared area of ​​the resource pool, wherein the target number of computing core groups is the number of computing core groups reclaimed from tasks with a task priority lower than critical level; and allocating the number of critical-level reserved core groups, the target number of computing core groups, and the capacity of critical-level memory blocks to the target task.

[0153] As an optional implementation provided in this application, the device further includes a resource adjustment module, configured to: execute resource monitoring primitives during the execution of the target task, collect resource indicators during the execution of the target task, including at least one of computing power utilization, memory utilization, memory page fault rate, and memory access latency; when the resource indicators do not meet a preset threshold, trigger a resource adjustment request to execute a dynamic adjustment primitive; the resource adjustment request includes the current resource usage and target resource usage of the target task; if the target resource usage is greater than the current resource usage, determine a new logical resource unit from the initialization resource pool and allocate it to the target task; if the target resource usage is less than the current resource usage, determine a portion of the logical resource units corresponding to the target task based on the target resource usage and the current resource usage; wherein the resource quantity of the portion of the logical resource units is greater than or equal to the task requirement of the target task; and release the portion of the logical resource units back to the initialization resource pool.

[0154] As an optional implementation provided in this application, the resource reclamation module 304 is used to: execute a resource reclamation primitive when the target task terminates, add a spinlock to the computing power pool, and move the computing core group of the target task from the working core group list back to the idle core group list; or, add a spinlock to the memory pool of the target task and move the memory block from the working memory block list back to the idle memory block list; if the memory block of the target task is consecutively located with the address of an adjacent memory block in the idle memory block list, then merge the memory block with the adjacent memory block.

[0155] For a description of the features in the embodiment corresponding to the resource management device of the operating system kernel, please refer to the relevant description of the embodiment corresponding to the resource management method of the operating system kernel, which will not be repeated here.

[0156] like Figure 4 As shown, embodiments of this application also provide an electronic device, including a memory 401 and a processor 402. The memory 401 stores a computer program, and the processor 402 is configured to run the computer program to execute the steps in any of the above-described embodiments of the resource management method of an operating system kernel.

[0157] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the resource management method of an operating system kernel.

[0158] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0159] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described embodiments of the resource management method for an operating system kernel.

[0160] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described embodiments of the resource management method of an operating system kernel.

[0161] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0162] The foregoing has provided a detailed description of a resource management method, apparatus, device, medium, and product for an operating system kernel provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A resource management method for an operating system kernel, characterized in that, include: In response to the request of the target task, a resource allocation primitive is executed to determine the target logical resource unit from the initialization resource pool and allocate the target logical resource unit to the target task; the initialization resource pool is the resource pool of the operating system kernel, including the computing power pool and the memory pool; The target logical resource unit includes a computing core group or a memory block; The resource isolation primitive is executed to isolate the target logical resource unit from the logical resource units corresponding to other tasks through a hardware isolation mechanism; The other tasks are any tasks other than the target task; The target task is executed based on the target logical resource unit; When the target task terminates, the resource reclamation primitive is executed to release the target logical resource unit back to the initialization resource pool; Before the method of responding to the request of the target task to execute the resource allocation primitive, determining the target logical resource unit from the initialized resource pool, and allocating the target logical resource unit to the target task, the method further includes: In response to a resource pool creation request from the operating system kernel, a pooling initialization primitive is executed to determine whether the request is to create a computing power pool or a memory pool; the resource pool creation request includes the total amount of resources. If a request is made to create a computing power pool, check whether the total amount of resources matches the number of processor cores. If so, generate a computing power pool identifier and initialize the built-in spin lock of the computing power pool, and create a list of idle core groups and a list of working core groups. If a memory pool is requested to be created, the total amount of resources is checked to see if it is within the available memory range of the node. If so, the built-in spin lock of the memory pool is initialized, and a list of free memory blocks and a list of working memory blocks are created.

2. The method according to claim 1, characterized in that, The step of executing a resource allocation primitive in response to a request from a target task, determining a target logical resource unit from an initialized resource pool, and allocating the target logical resource unit to the target task includes: In response to the request of the target task, execute the resource allocation primitive to determine the task resource requirements of the target task; If the task resource requirement points to the computing power pool, then a spin lock is added to the computing power pool, and a computing core group that meets the task resource requirement is determined from the list of idle core groups in the computing power pool and allocated to the target task. If the task resource requirement points to a memory pool, then a spinlock is added to the memory pool, and a memory block that meets the task resource requirement is determined from the list of free memory blocks in the memory pool and allocated to the target task.

3. The method according to claim 1, characterized in that, The execution resource isolation primitive isolates the target logical resource unit from the logical resource units corresponding to other tasks through a hardware isolation mechanism, including: Execute the resource isolation primitive to bind the computing core group in the target logical resource unit to the target task and disable the preemption function of the computing core group; Alternatively, the memory block in the target logical resource unit can be bound to the target task, and the memory block can be encrypted.

4. The method according to claim 1, characterized in that, Before the method of responding to the request of the target task to execute the resource allocation primitive, determining the target logical resource unit from the initialized resource pool, and allocating the target logical resource unit to the target task, the method further includes: In response to the resource pool creation request of the operating system kernel, the pooling initialization primitive is executed to calculate the total capacity of the resource pool of the operating system kernel, including the total number of core groups and the total number of memory blocks; Based on the total capacity of the resource pool and the preset ratio corresponding to different task priorities, the resource quantity of the reserved area is calculated; the reserved area resources include the number of reserved computing cores and the reserved capacity of memory blocks corresponding to different task priorities.

5. The method according to claim 1, characterized in that, Before the method responds to the request of the target task by executing the resource allocation primitive, determines the target logical resource unit from the initialized resource pool, and allocates the target logical resource unit to the target task, the method further includes: In response to a service quality task registration request, execute the service quality task registration primitives to determine the task priority identifier and task resource requirements; The reserved area corresponding to the task priority identifier is determined from the resource pool based on the task priority identifier; Determine whether the remaining resource quantity in the reserved area is greater than or equal to the resource requirement of the task. If so, a locking operation is performed on the resource reserve to ensure that the resource reserve is not occupied by tasks other than the quality of service task.

6. The method according to claim 1, characterized in that, The step of executing a resource allocation primitive in response to a request from a target task, determining a target logical resource unit from an initialized resource pool, and allocating the target logical resource unit to the target task includes: If the target task is a critical task, the number of critical reserved core groups and the capacity of critical memory blocks that meet the requirements of the critical task are selected from the critical reserved area of ​​the resource pool. If the number of critical-level reserved core groups in the critical-level reserved area does not meet the requirements of the critical-level task, then the target number of computing core groups will be preempted from the shared area of ​​the resource pool; the target number of computing core groups is the number of computing core groups reclaimed from tasks with a task priority lower than the critical level. The number of critical-level reserved core groups, the number of target computing core groups, and the capacity of the critical-level memory blocks are allocated to the target task.

7. The method according to claim 1, characterized in that, The method further includes: During the execution of the target task, resource monitoring primitives are executed to collect resource metrics during the execution of the target task. The resource metrics include at least one of computing power utilization, memory utilization, memory page fault rate, and memory access latency. When the resource metric does not meet the preset threshold, a resource adjustment request is triggered to execute a dynamic adjustment primitive; the resource adjustment request includes the current resource usage and the target resource usage of the target task; If the target resource usage is greater than the current resource usage, then a new logical resource unit is determined from the initial resource pool and allocated to the target task; If the target resource usage is less than the current resource usage, then based on the target resource usage and the current resource usage, a portion of the logical resource units corresponding to the target task are determined; wherein, the resource quantity of the portion of the logical resource units is greater than or equal to the task requirement of the target task; and the portion of the logical resource units are released back to the initialization resource pool.

8. The method according to claim 1, characterized in that, The step of executing a resource reclamation primitive when the target task terminates, releasing the target logical resource unit back to the initialization resource pool, includes: When the target task terminates, the resource reclamation primitive is executed, a spin lock is added to the computing pool, and the computing core group of the target task is moved from the working core group list back to the idle core group list. Alternatively, a spinlock can be added to the memory pool of the target task, and the memory block can be moved from the working memory block list back to the free memory block list; if the memory block of the target task has a contiguous address with the adjacent memory block in the free memory block list, then the memory block can be merged with the adjacent memory block.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the resource management method of the operating system kernel as described in any one of claims 1 to 8 when executing the computer program.

Images