Resource allocation method, resource processing method, device, storage medium, and program product

Abstract

Embodiments of the present invention provide a resource allocation method, a resource processing method, a device, a storage medium, and a program product. In the resource allocation method, a resource allocation request of a Pod is acquired, and then a target resource allocation component is called to pre-allocate to the Pod a plurality of groups of huge-page memory files corresponding to a plurality of NUMA nodes on a target node, and returns directories of the plurality of groups of huge-page memory files to a node agent. The node agent allocates the plurality of groups of huge-page memory files to the Pod. Therefore, when a container orchestration engine does not support allocation, based on the granularity of NUMA nodes, of huge-page memory resources to the Pod, pre-allocation of the huge-page memory resources based on the granularity of the NUMA nodes is achieved by means of the target resource allocation component, thereby facilitating containerized deployment of a target application in the Pod and satisfying the high-performance processing requirements of the target application. In addition, the target application in the Pod does not need to create huge-page memory files during startup, thereby further increasing the startup speed of the target application.

Description

Resource allocation, processing methods, equipment, storage media and program products Technical Field

[0001] This disclosure relates to the field of virtualization technology, and in particular to a resource allocation, processing method, device, storage medium, and program product. Background Technology

[0002] Virtualization is a technology that allows multiple logical computing resources to be created and run on a single physical computing resource (such as a server, storage device, or network resource). With the rapid development of technologies such as cloud computing and big data, containerization has gradually become the mainstream lightweight alternative to virtualization. Compared with traditional virtual machines, containers share the host machine's operating system kernel and can package applications and their dependencies together, enabling them to run consistently in various environments, thus achieving a more lightweight isolated environment.

[0003] Container orchestration engines are crucial for managing large-scale containerized environments. They provide frameworks and tools for managing container lifecycles, deployments, scaling, and networking, reducing the complexity of handling large numbers of containers in production environments. Currently, container orchestration engines offer increasingly robust resource management for containers, now supporting the allocation and limiting of huge pages (Hugepages) of memory resources. This enables containerization for applications / services that heavily rely on huge pages. A huge page refers to a memory page larger than the standard 4KiB; for example, a huge page is typically 2MiB or 1GiB. It reduces the number of page table entries, thereby improving memory access efficiency.

[0004] However, existing container orchestration engines still lack fine-grainedness in allocating and managing large page memory resources. For example, they still cannot support the deployment of applications that use Non-Uniform Memory Access (NUMA) mechanisms to access large page memory. Therefore, a new solution is needed. Summary of the Invention

[0005] This disclosure provides, in various aspects, a resource allocation, processing method, apparatus, storage medium, and program product for pre-allocating NUMA-granular large page memory resources for containerized target applications.

[0006] This disclosure provides a resource allocation method, comprising: obtaining a resource allocation request from a target container unit, the target container unit being used to run a target application that accesses memory resources based on a non-uniform memory access mechanism, the target node where the target container unit is located including multiple non-uniform memory nodes; invoking a target resource allocation component to pre-allocate at least one set of large page memory files according to the resource allocation request, the at least one set of large page memory files corresponding to at least one non-uniform memory node among the multiple non-uniform memory nodes; allocating the at least one set of large page memory files to the target container unit according to the directory of the at least one set of large page memory files, the target application being used to directly load the at least one set of large page memory files and access the at least one set of large page memory files using the non-uniform memory access mechanism.

[0007] Optionally, invoking the target resource allocation component to pre-allocate at least one set of large page memory files according to the resource allocation request includes: parsing the resource allocation request to obtain the declaration information of the container storage interface; if the declaration information contains the identification information of the target resource allocation component, then invoking the target resource allocation component to pre-allocate the at least one set of large page memory files according to the resource allocation request.

[0008] Optionally, allocating the at least one set of large page memory files to the target container unit according to the directory of the at least one set of large page memory files includes: within the target container unit, determining the large page memory directory corresponding to each of the at least one non-uniform memory nodes; and calling the container storage interface to mount the directory of the at least one set of large page memory files to the large page memory directory corresponding to each of the at least one non-uniform memory nodes according to the correspondence between the at least one set of large page memory files and the at least one non-uniform memory node.

[0009] This disclosure also provides a resource allocation method, comprising: receiving a resource allocation request from a node agent for a target container unit, the target container unit being used to run a target application that accesses memory resources based on a non-uniform memory access mechanism, the target node where the target container unit is located including multiple non-uniform memory nodes; pre-allocating at least one set of large page memory files according to the resource allocation request, the at least one set of large page memory files corresponding to at least one non-uniform memory node among the multiple non-uniform memory nodes; and returning the directory of the at least one set of large page memory files to the node agent, the directory of the at least one set of large page memory files being used to enable the node agent to allocate the at least one set of large page memory files to the target container unit.

[0010] Optionally, according to the resource allocation request, pre-allocating at least one set of large page memory files includes: determining, according to the resource allocation request, at least one non-uniform memory node from the plurality of non-uniform memory nodes to which large page memory resources are to be allocated; pre-allocating at least one local physical memory corresponding to the at least one non-uniform memory node for the target container unit in the physical memory of the target node, wherein the addresses of any local physical memory are contiguous; and creating large page memory files in the local physical memory pre-allocated to the at least one non-uniform memory node respectively to obtain the at least one set of large page memory files.

[0011] Optionally, it further includes: during the process of pre-allocating the at least one contiguous local physical memory for the target container unit, if there is a pending resource allocation request for at least one other container unit, the resource allocation request for the at least one other container unit located on the target node is blocked.

[0012] This disclosure also provides a resource processing method, comprising: responding to a startup operation of a target application in a target container unit, determining a directory of at least one set of large page memory files allocated to the target container unit and corresponding to at least one non-uniform memory node; wherein the at least one set of large page memory files is pre-allocated to the target container unit using the resource allocation method provided in this disclosure; loading the at least one set of large page memory files according to the directory of the at least one set of large page memory files, and mapping the at least one set of large page memory files to the virtual address space corresponding to the target application, so as to access the at least one set of large page memory files in the virtual address space based on a non-uniform memory access mechanism.

[0013] Optionally, determining the directory of at least one set of huge page memory files corresponding to multiple non-uniform memory nodes allocated to the target container unit includes: within the target container unit, determining the huge page memory directory corresponding to each of the at least one non-uniform memory nodes; and reading the directory of at least one set of huge page memory files corresponding to each of the at least one non-uniform memory nodes according to the huge page memory directory corresponding to each of the at least one non-uniform memory nodes.

[0014] This disclosure also provides a resource allocation system, including: a scheduler, a target node, and a target resource allocation component; the target node runs a node agent and a target container unit, and the target container unit runs a target application; the target node includes multiple non-uniform memory nodes, and the target application accesses memory resources based on a non-uniform memory access mechanism; wherein, the scheduler is used to: respond to the deployment request of the target container unit and schedule the target container unit to the target node; the node agent is used to: obtain the resource allocation request of the target container unit; call the target resource allocation component to pre-allocate at least one set of large page memory files according to the resource allocation request, the at least one set of large page memory files corresponding to at least one non-uniform memory node among the multiple non-uniform memory nodes; and pre-allocate memory resources according to the at least one set of large page memory files. The target resource allocation component is configured to: receive the resource allocation request, pre-allocate at least one set of large page memory files corresponding to the at least one non-uniform memory node, and return the directory of the at least one set of large page memory files to the node agent; the target application is configured to: respond to the startup operation of the target application, determine the directory of the at least one set of large page memory files allocated to the target container unit corresponding to the at least one non-uniform memory node; load the at least one set of large page memory files according to the directory of the at least one set of large page memory files, and map the at least one set of large page memory files to the virtual address space corresponding to the target application, so as to access the at least one set of large page memory files in the virtual address space based on the non-uniform memory access mechanism.

[0015] This disclosure also provides an electronic device, including: a memory and a processor; the memory is used to store one or more computer instructions; the processor is used to execute the one or more computer instructions to perform the steps in the method provided in this disclosure.

[0016] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps of the method provided in this disclosure.

[0017] This disclosure also provides a computer program product, including: a computer program / instructions, which, when executed by a processor, can implement the steps in the method provided in this disclosure.

[0018] In this embodiment, after obtaining the resource allocation request of the target container unit, the target resource allocation component can be invoked to pre-allocate multiple sets of large page memory files corresponding to multiple non-uniform memory nodes on the target node for the target container unit, and the directory of the multiple sets of large page memory files can be returned to the node agent. The node agent can allocate the multiple sets of large page memory files to the target container unit, so that the target application running in the target container unit can access at least one set of large page memory files on the target node based on the non-uniform memory access mechanism. Furthermore, in the case where the container orchestration engine does not support allocating large page memory resources to the target container unit at the granularity of non-uniform memory nodes, the target resource allocation component is used to realize the pre-allocation of large page memory resources at the granularity of non-uniform memory nodes, which facilitates the containerized deployment of the target application in the target container unit and meets the high-performance processing requirements of the target application. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings:

[0020] Figure 1 is a schematic diagram of allocating large page memory resources to DPDK programs in a Pod based on a control group;

[0021] Figure 2 is a schematic diagram of multiple Pods requesting massive page memory resources in a cross-application process.

[0022] Figure 3 is a schematic diagram of the structure of a resource allocation system provided in an exemplary embodiment of the present disclosure;

[0023] Figure 4 is a schematic diagram of the internal structure of a target node provided in an exemplary embodiment of this disclosure;

[0024] Figure 5 is a flowchart illustrating the execution of the resource allocation method provided in an exemplary embodiment of this disclosure on the node agent side.

[0025] Figure 6 is a flowchart illustrating the execution of the resource allocation method provided in an exemplary embodiment of this disclosure on the target resource allocation component side.

[0026] Figure 7 is a flowchart illustrating the execution of a resource processing method provided in an exemplary embodiment of the present disclosure on the target application side.

[0027] Figure 8 is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this disclosure. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0029] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. “Multiple” generally includes at least two, but does not exclude the inclusion of at least one.

[0030] It should be understood that the term "and / or" used in this document describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0031] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a product or system that comprises a list of elements includes those elements, as well as other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase “comprising one…” does not exclude the presence of other identical elements in the product or system that includes said element.

[0032] Container orchestration engines are used to deploy, scale, and manage containerized applications. An orchestration engine is deployed in a collection of physical or virtual machines called a cluster. A cluster consists of a control plane and nodes. The control plane is responsible for managing the state and configuration of the entire cluster. The control plane includes at least an API (Application Programming Interface) server, a scheduler, and a key-value store. The API server is the front end of the control plane, providing the entry point for cluster operations and handling data validation and configuration. The scheduler allocates unassigned Pods to appropriate nodes. The key-value store stores all cluster data.

[0033] The nodes in the cluster work together to run and manage containerized applications. Each node can be a physical server or a virtual machine. Each node runs a node agent, which is responsible for communicating with the API server and ensuring that the containers on the node run as expected. A node can run one or more container units (Pods). A Pod is the smallest deployable and schedulable unit in a container orchestration engine, and a Pod can contain one or more containers.

[0034] Currently, container orchestration engines offer increasingly sophisticated resource management for containers, now supporting the request and limitation of hugepage resources. This enables containerization of applications / services that heavily rely on hugepage resources. Within a container orchestration engine, users can define Pod configuration data through the Pod's configuration file. This configuration data includes descriptions of the Pod's memory resource allocation. Hugepage resources are typically fixed in size; for example, a single hugepage is usually 1GB. The configuration file allows Pods to request hugepage resources through the `limits` and `requests` fields. The `requests` field defines the minimum number of hugepage resources a Pod requires, while the `limits` field defines the maximum number of hugepage resources a Pod can use.

[0035] Cgroups are a kernel mechanism in Linux (an open-source operating system) used to restrict, specify, and isolate the resource usage of a collection of processes. These processes may use resources including, but not limited to, CPU (Central Processing Unit), memory, and disk I / O (Input / Output). In container orchestration engines, nodes can manage Hugepages based on Cgroups to achieve fine-grained control over the allocation and use of Hugepage resources. A Hugepage resource allocation process based on the Cgroup mechanism is as follows:

[0036] 1. Users request Hugepage resources from the container orchestration engine's scheduler through the Pod's configuration file.

[0037] 2. After the scheduler schedules the Pod to a node, the node agent on the node can create a Cgroup of Hugepage resources for the Pod.

[0038] 3. After the Pod runs on the node, the process inside the Pod creates the Hugepage file through the MMAP (Memory-Mapped File) system call.

[0039] 4. Cgroup limits the Hugepage memory used by a process.

[0040] The Hugepage resources allocated by the above method do not have NUMA attributes. This allows the container orchestration engine to control how many Hugepage resources a Pod uses, but it cannot control which NUMA Hugepage resource a Pod uses. Consequently, it cannot support the deployment of some applications that use NUMA mechanisms to access large page memory.

[0041] Secondly, in this method, the creation and mapping of Hugepage files are completed through standard Linux system calls. When a service running in a Pod needs to request a large number of Hugepages, it takes a considerable amount of time to execute the Hugepage file creation and mapping operations. For some services, all Hugepage files are deleted when the process is shut down, and the Hugepage file creation and mapping operations are re-executed when the process is restarted. Consequently, this leads to a longer overall startup time for services running in the Pod.

[0042] Furthermore, when multiple Pods on the same node start simultaneously, the service processes within these Pods may concurrently request Hugepage resources. In this situation, the service processes within multiple Pods may alternately request Hugepage resources via MMAP system calls, leading to a situation where the physical memory corresponding to Hugepage resources within the same Pod is intermittently discontinuous, as shown in Figure 2. Under these circumstances, the processing performance of the service processes within the Pod may degrade.

[0043] To address the aforementioned technical problems, a solution is provided in some embodiments of this disclosure. The technical solutions provided by the embodiments of this disclosure are described in detail below with reference to the accompanying drawings.

[0044] Figure 3 is a schematic diagram of the structure of a resource allocation system provided in an exemplary embodiment of this disclosure. This resource allocation system is built on a container orchestration engine. As shown in Figure 3, the resource allocation system 30 includes a scheduler 31, multiple nodes (such as target nodes 32), and a target resource allocation component 33. The target node 32 can be any node in the container orchestration engine. As shown in Figure 3, a node agent 34 and a target container unit 35 run on the target node 32, and a target application 36 runs in the target container unit 35. The target node 32 includes multiple non-uniform memory nodes (hereinafter referred to as NUMA nodes), such as NUMA0 and NUMA1 shown in Figure 3. The target application 36 can access the memory resources on the target node 32 based on a non-uniform memory access mechanism (hereinafter referred to as NUMA mechanism) to provide high-performance services.

[0045] Target node 32 is designed based on a NUMA architecture. In a NUMA architecture, a computer system consists of multiple NUMA nodes. Each NUMA node contains one or more processors and local memory, and can be connected to other NUMA nodes via a high-speed network or bus. The speed at which a processor in a NUMA node accesses its own local memory is greater than the speed at which it accesses the memory of another NUMA node via a network or bus. The number of NUMA nodes included in target node 32 is usually fixed, determined by the motherboard design of target node 32 and the number and type of CPUs installed. For example, when target node 32 uses a multi-core CPU, it can allocate its own local memory to each CPU, forming multiple NUMA nodes. When the server motherboard design allows multiple CPUs to work collaboratively, local memory can be allocated to the collaboratively working CPUs, forming a large NUMA node.

[0046] In this embodiment, when the target application 36 in the target container unit 35 accesses memory resources based on the NUMA mechanism, the scheduler 31 can respond to the deployment request of the target container unit 35 and schedule the target container unit 35 to the target node 32 containing multiple NUMA nodes to meet the NUMA architecture requirements of the target application 36.

[0047] After scheduler 31 schedules target container unit 35 to target node 32, node agent 34 and target resource allocation component 33 on target node 32 can collaboratively allocate Hugepage resources with NUMA attributes to target container unit 35. The NUMA attribute of Hugepage resources means that the Hugepage resources are allocated to specific NUMA nodes, thereby ensuring that data requested and processed by the CPU in the NUMA node can be stored in the CPU's local memory, thus minimizing memory access latency.

[0048] The target resource allocation component 33 can be a plug-in program capable of communicating with the node agent 34 and the large page file system in the kernel space of the target node 32, and capable of performing pre-allocation operations of Hugepage resources. The target resource allocation component 33 can run on the target node 32, or on other nodes in the resource allocation system 30. These other nodes can be regular servers or cloud servers; this embodiment is not limited to any particular node. In some embodiments, the target resource allocation component 33 can be a CSI driver developed based on the Container Storage Interface (CSI) standard. In container orchestration engines, CSI provides a standard method to connect external storage systems to a cluster of container orchestration engines. CSI defines a set of APIs for enabling communication between storage systems and the cluster of container orchestration engines to achieve lifecycle management of storage volumes. In this embodiment, the target resource allocation component 33, conforming to the CSI standard, can create large page memory files in the physical memory of the target node 32, making the created large page memory files usable by the target container unit 35, thereby providing physical memory to the containerized target application 36 in the form of large page memory files.

[0049] As shown in Figure 4, the target resource allocation component 33 may include a CSI identification module and a huge page memory management module. The CSI identification module is used to register the CSI driver with the node agent 34 based on the CSI identifier, enabling the node agent 34 to be aware of the huge page file system connected to the CSI driver. The huge page memory management module communicates with the huge page file system in the kernel space of the target node 32 to manage huge page memory based on the huge page file system. The resource allocation system 30 will be further explained below with reference to Figure 4, using the target node 32 as an example.

[0050] In the resource allocation system 30, the node agent 34 is used to: obtain the resource allocation request from the target container unit 35, invoke the target resource allocation component 33, and pre-allocate at least one set of Hugepage memory files according to the resource allocation request. This resource allocation request may be initiated by the user through the container orchestration engine's API server. In some embodiments, the user may submit a configuration file for the target container unit 35 through the API server. This configuration file describes the target container unit 35's requirements for Hugepage resources. For example, in the configuration file, the minimum number of Hugepage resources required by the target container unit 35 can be defined as 10G through the `requests` field, and the maximum number of Hugepage resources that the target container unit 35 can use can be defined as 10G through the `limits` field.

[0051] In the resource allocation system 30, the target resource allocation component 33 is used to: receive resource allocation requests from the target container unit 35 sent by the node agent 34, pre-allocate at least one set of large page memory files, and return the directory of the at least one set of large page memory files to the node agent 34. The at least one set of large page memory files corresponds to at least one NUMA node among multiple NUMA nodes on the target node 32. Each NUMA node can correspond to a set of large page memory files, and a set of large page memory files can contain one or more large page memory files. The directory of any set of large page memory files refers to the storage address of that set of large page memory files on the target node 32. Pre-allocation means allocating resources to the target application 36 before it starts, thereby reducing the risk of insufficient remaining allocable large page memory resources affecting the processing performance of the target application 36 during its operation. Optionally, the target resource allocation component 33 conforming to the CSI standard can support node-published volumes and provide a node-published volume method. The node-published volume is a local storage resource on the target node 32. When the node agent 34 sends a resource allocation request to the target resource allocation component 33, it can invoke the Node-Published Volume method of the target resource allocation component 33 through a remote procedure call (RPC). This method can create at least one large page memory resource pool corresponding to each NUMA node in the physical memory of the target node 32, and each large page memory resource pool contains a set of large page memory files.

[0052] Accordingly, the node agent 34 is used to: receive at least one set of directories of massive page memory files returned by the resource allocation component 33 according to the resource allocation request, and allocate the at least one set of massive page memory files to the target container unit 35 according to the directory of the at least one set of massive page memory files.

[0053] The target application 36 is configured to: respond to a startup operation of the target application 36, determine the directory of at least one set of huge page memory files allocated to the target container unit 35 and corresponding to the at least one NUMA node, and map the at least one set of huge page memory files to the virtual address space corresponding to the target application 36 according to the directory of the at least one set of huge page memory files. Furthermore, when the target application 36 needs to access memory resources during operation, it can access the at least one set of huge page memory files in the virtual address space based on a non-uniform memory access mechanism. The startup operation of the target application 36 may be a user-triggered startup operation after the target application 36 has completed containerized deployment; or it may be a timed startup operation of the target application 36; or it may be a startup operation driven by a specific script; or it may be a restart operation after the target application 36's process has stopped, etc., and this embodiment includes but is not limited to these.

[0054] The virtual address space refers to a virtual memory region allocated by the operating system to user-space processes (i.e., the process of the target application 36). At least one set of large page memory files is mapped to the virtual address space corresponding to the target application 36. This allows the user-space processes of the target application 36 to directly access these large page memory files. The mapping of large page memory files to virtual address space can be achieved through memory mapping. Based on memory mapping, the contents of the large page memory files can be directly read and written in memory without the need for traditional file I / O calls.

[0055] In this embodiment, the startup operation of the target application 36 includes the initial process startup operation after the target application 36 is deployed in the target container unit 35, and may also include the restart operation after the target application 36's process stops. In the restart scenario of the target application 36, the restarted target application 36 can directly load the directory of at least one set of large page memory files in the large page memory directory of the target container unit 35, and map at least one set of large page memory files to the virtual address space corresponding to the target application 36 according to the directory of at least one set of large page memory files. Therefore, even if the target application 36 releases at least one set of large page memory files when the process stops, after restarting, the target application 36 does not need to re-request large page memory resources through system calls, but can directly load the large page memory files in the large page memory directory and map them to obtain large page memory resources again. That is to say, even if the target application 36 restarts, the required large page memory resources can be quickly allocated to the target application 36, thereby improving the startup speed of the target application 36.

[0056] Based on the above implementation, in the case where the container orchestration engine does not support allocating large page memory resources to Pods at the granularity of NUMA nodes, the target resource allocation component 33 is used to achieve the pre-allocation of large page memory resources at the granularity of NUMA nodes, which facilitates the containerized deployment of the target application in the Pod and meets the high-performance processing requirements of the target application.

[0057] In some optional embodiments, the configuration file of the target container unit 35 submitted by the user through the API server may include declaration information. This declaration information is used to declare the identifier of the target resource allocation component 33 so as to facilitate the invocation of the target resource allocation component 33. Optionally, this declaration information may be CSI declaration information, or it may be API invocation declaration information of the target resource allocation component 33, or it may be the declaration information of a script file that can invoke the target resource allocation component 33 at runtime. This embodiment does not impose any limitations.

[0058] Accordingly, when node agent 34 invokes target resource allocation component 33 to pre-allocate at least one set of large page memory files according to the resource allocation request, it specifically performs the following: parses the resource allocation request and obtains the declaration information of the container storage interface. If the declaration information contains the identification information of target resource allocation component 33, then node agent 34 can invoke target resource allocation component 33 to pre-allocate the at least one set of large page memory files according to the resource allocation request.

[0059] Taking the declaration information implemented as CSI as an example, in some embodiments, the CSI declaration information includes the identification information of the target resource allocation component 33, which may be the filename of the CSI driver. The node agent 34 can call the CSI driver based on the filename of the CSI driver. If the declaration information of the configuration files of multiple different Pods submitted by the user all include the identification of the target resource allocation component 33, then in the resource allocation system 30, the target resource allocation component 33 can serve as a unified entry point for pre-allocating the large page memory resources corresponding to each of the multiple different Pods. In some embodiments, when pre-allocating the large page memory resources corresponding to each Pod, the target resource allocation component 33 can obtain the number of NUMA nodes of the node where each Pod is located, and allocate one or more sets of large page memory files to each Pod based on the number of NUMA nodes. In other embodiments, when pre-allocating the large page memory resources corresponding to each Pod, the target resource allocation component 33 can obtain the number of NUMA nodes specified in the resource allocation request, and pre-allocate one or more sets of large page memory files to each Pod based on the specified number of NUMA nodes. Based on this implementation, when a user needs to allocate huge page memory resources according to NUMA nodes, they can customize the declaration information in the Pod's configuration file and add the identification information of the target resource allocation component 33 to the declaration information. This allows the node agent 34 to be instructed to decentralize the huge page memory resource allocation operation to the target resource allocation component 33, thereby invoking the target resource allocation component 33 to allocate huge page memory resources with NUMA attributes to the Pod. Furthermore, even when the node agent 34 does not support allocating huge page memory resources to the Pod based on NUMA nodes, the target resource allocation component 33 can be used to implement the allocation operation of huge page memory resources based on NUMA attributes.

[0060] In some exemplary embodiments, when the node agent 34 allocates the at least one set of large page memory files to the target container unit 35 according to the directory of the at least one set of large page memory files, it may associate the at least one set of large page memory files with the Cgroup corresponding to the target container unit 35 so as to allocate the multiple sets of large page memory resources to the target container unit 35 for use.

[0061] In other exemplary embodiments, when the node agent 34 allocates the at least one set of large page memory files to the target container unit 35 according to the directory of the at least one set of large page memory files, it can mount the at least one set of large page memory files into the interior of the target container unit 35 as a storage volume.

[0062] Optionally, the node agent 34 can determine the huge page memory directory corresponding to each of the at least one NUMA node within the target container unit 35, and call the container storage interface (i.e., CSI) to mount the directories of the at least one set of huge page memory files to the huge page memory directories corresponding to the at least one NUMA node, based on the correspondence between the at least one set of huge page memory files and the at least one NUMA node. The huge page memory target is typically the / dev / hugepages directory.

[0063] On target node 32, each NUMA node can mount a hugepage file system instance, such as a Hugetlbfs instance (a Linux file system that allows applications to use huge pages). The hugepage memory directory for each NUMA node points to the Hugetlbfs instance corresponding to that NUMA node. The Hugetlbfs file system is a special file system in the Linux kernel used to manage hugepage memory. Each NUMA node corresponds to a / dev / hugepages directory. For example, target node 32 includes NUMA0 and NUMA1 nodes. NUMA0 corresponds to the / dev / hugepages_node0 directory, and NUMA1 corresponds to the / dev / hugepages_node1 directory. The hugepage memory directories corresponding to NUMA0 and NUMA1 nodes can be mounted as volumes within target container unit 35, allowing containers in target container unit 35 to use the hugepage memory files corresponding to NUMA0 and NUMA1 nodes.

[0064] Based on this, after obtaining a set of huge page memory files corresponding to the NUMA0 node, these huge page memory files can be mounted to the / dev / hugepages_node0 directory; after obtaining a set of huge page memory files corresponding to the NUMA1 node, these huge page memory files can be mounted to the / dev / hugepages_node1 directory.

[0065] Based on the above implementation, the target application in the target container unit 35 can access the huge page memory file corresponding to the NUMA0 node through the / dev / hugepages_node0 directory, and access the huge page memory file corresponding to the NUMA1 node through the / dev / hugepages_node1 directory, thereby realizing access to huge page memory resources based on the NUMA mechanism. In some high-performance processing scenarios, the target application can access the local memory corresponding to different CPUs through different CPUs. For any CPU, the speed of accessing local memory is greater than the speed of accessing memory on another NUMA node through the network or bus, which can effectively reduce access latency and improve processing efficiency.

[0066] For example, in a massively parallel processing scenario, the target application used to perform data processing tasks is deployed in a target container unit. Assume the target container unit contains NUMA1 nodes and NUMA2 nodes. NUMA1 node contains CPU1 and its local memory R1, and NUMA2 node contains CPU2 and its local memory R2. The target application can utilize CPU1 and CPU2 to execute data processing tasks in parallel. Specifically, the target application can use CPU1 to read data from its local memory R1 and store intermediate data generated during computation in its local memory R1 for later use. Similarly, the target application can use CPU2 to read data from its local memory R2 and store intermediate data generated during computation in its local memory R2 for later use. In this implementation, for CPU1 and CPU2, the data to be computed and intermediate result data are stored in their respective local memories. A single CPU does not need to access the local memory of other NUMA nodes through a network or bus, thus effectively improving data processing efficiency.

[0067] For example, in a graphics rendering scenario, in a multi-NUMA node architecture, different rendering tasks can be assigned to different NUMA nodes. For each rendering task, after determining its assigned NUMA node, the corresponding rendering thread is bound to the CPU within that NUMA node to ensure that the rendering thread can access the CPU's local memory. Furthermore, when rendering threads in multiple NUMA nodes execute rendering tasks in parallel, they can primarily access the local memory of their respective bound CPUs without needing to access the local memory of other NUMA nodes, thereby reducing data transfer latency and improving rendering efficiency.

[0068] In some exemplary embodiments, when the target resource allocation component 33 pre-allocates at least one set of huge page memory files corresponding to the at least one NUMA node for the target container unit 35, it can determine at least one NUMA node to be allocated huge page memory resources from multiple NUMA nodes on the target node 32 according to the resource allocation request. Optionally, the resource allocation request can specify the number of at least one NUMA node to be allocated huge page memory resources, or it can specify the identifier of at least one NUMA node to be allocated huge page memory resources. After determining at least one NUMA node, the target resource allocation component 33 can pre-allocate multiple local physical memories corresponding to the at least one NUMA node for the target container unit 35 in the physical memory of the target node 32, wherein the addresses of any local physical memory are contiguous. Herein, one NUMA node corresponds to one contiguous local physical memory, which means that the memory block corresponding to the NUMA node is contiguous in the physical address space. Then, huge page memory files can be created in the local physical memory pre-allocated to the at least one NUMA node respectively, to obtain at least one set of huge page memory files corresponding to the at least one NUMA node.

[0069] In this implementation, the memory blocks corresponding to a single NUMA node are contiguous, which helps to reduce memory access across NUMA nodes in multi-threaded or multi-process scenarios, thereby improving concurrency performance.

[0070] Optionally, in some embodiments, to ensure that each container unit is pre-allocated with contiguous local physical memory corresponding to the NUMA node, the target resource allocation component 33 can be used as a unified large page memory resource allocation entry point.

[0071] Continuing with the example of target container unit 35, during the process of pre-allocating multiple contiguous local physical memory corresponding to the at least one NUMA node for target container unit 35, if there is a pending resource allocation request from at least one other container unit located on the target node 32, the resource allocation request from that other container unit is blocked. This ensures that local physical memory is not cross-allocated to different container units on the target node 32 at the same time, thus guaranteeing the continuity of local physical memory for the same container unit.

[0072] Optionally, when the target resource allocation component 33 receives resource allocation requests from multiple container units, it can process these requests serially to avoid overlapping the allocation of local physical memory to different container units, thereby ensuring the continuity of the local physical memory corresponding to a single container unit. For example, when a resource allocation request for target container unit 35 is received, if there are other resource allocation requests that have not yet completed resource pre-allocation, the target resource allocation component 33 can add the resource allocation request for target container unit 35 to the waiting queue. The target resource allocation component 33 can process the resource allocation requests added to the waiting queue one by one in a first-in, first-out order.

[0073] Figure 5 is a flowchart illustrating the execution of a resource allocation method on the node agent side according to an exemplary embodiment of the present disclosure. The method may include the steps shown in Figure 5:

[0074] Step 501: Obtain the resource allocation request of the target container unit. The target container unit is used to run the target application that accesses memory resources based on a non-uniform memory access mechanism. The target node where the target container unit is located includes multiple non-uniform memory nodes.

[0075] Step 502: Invoke the target resource allocation component and pre-allocate at least one set of large page memory files according to the resource allocation request. The at least one set of large page memory files corresponds to at least one non-uniform memory node among the multiple non-uniform memory nodes.

[0076] Step 503: Based on the directory of the at least one set of large page memory files, allocate the at least one set of large page memory files to the target container unit. The target application is used to directly load the at least one set of large page memory files and access the at least one set of large page memory files using the non-uniform memory access mechanism.

[0077] Optionally, invoking the target resource allocation component to pre-allocate at least one set of large page memory files according to the resource allocation request includes: parsing the resource allocation request to obtain the declaration information of the container storage interface; if the declaration information contains the identification information of the target resource allocation component, then invoking the target resource allocation component to pre-allocate the at least one set of large page memory files according to the resource allocation request.

[0078] Optionally, allocating the at least one set of large page memory files to the target container unit according to the directory of the at least one set of large page memory files includes: within the target container unit, determining the large page memory directory corresponding to each of the at least one non-uniform memory nodes; and calling the container storage interface to mount the directory of the at least one set of large page memory files to the large page memory directory corresponding to each of the at least one non-uniform memory nodes according to the correspondence between the at least one set of large page memory files and the at least one non-uniform memory node.

[0079] In this embodiment, after obtaining the resource allocation request from the Pod, the node agent can invoke the target resource allocation component to pre-allocate at least one set of huge page memory files corresponding to multiple NUMA nodes on the target node for the Pod. After obtaining the directory of at least one set of huge page memory files, the node agent can allocate the at least one set of huge page memory files to the Pod, so that the target application running in the Pod can access the at least one set of huge page memory files on the target node based on the NUMA access mechanism. Therefore, in the case where the container orchestration engine does not support allocating huge page memory resources to the Pod at the granularity of NUMA nodes, the target resource allocation component is used to achieve the pre-allocation of huge page memory resources at the granularity of NUMA nodes, which facilitates the containerized deployment of the target application in the Pod and meets the high-performance processing requirements of the target application.

[0080] Figure 6 is a flowchart illustrating the execution of a resource allocation method provided in an exemplary embodiment of this disclosure on the side of a target resource allocation component. The method may include the steps shown in Figure 6:

[0081] Step 601: Receive the resource allocation request of the target container unit sent by the node agent. The target container unit is used to run the target application that accesses memory resources based on the non-uniform memory access mechanism. The target node where the target container unit is located includes multiple non-uniform memory nodes.

[0082] Step 602: Based on the resource allocation request, pre-allocate at least one set of large page memory files, wherein the at least one set of large page memory files corresponds to at least one non-uniform memory node among the plurality of non-uniform memory nodes.

[0083] Step 603: Return the directory of the at least one set of large page memory files to the node agent. The directory of the at least one set of large page memory files is used to enable the node agent to allocate the at least one set of large page memory files to the target container unit.

[0084] Optionally, according to the resource allocation request, pre-allocating at least one set of large page memory files includes: determining, according to the resource allocation request, at least one non-uniform memory node from the plurality of non-uniform memory nodes to which large page memory resources are to be allocated; pre-allocating at least one local physical memory corresponding to the at least one non-uniform memory node for the target container unit in the physical memory of the target node, wherein the addresses of any local physical memory are contiguous; and creating large page memory files in the local physical memory pre-allocated to the at least one non-uniform memory node respectively to obtain the at least one set of large page memory files.

[0085] Optionally, it further includes: during the process of pre-allocating the at least one contiguous local physical memory for the target container unit, if there is a pending resource allocation request for at least one other container unit, the resource allocation request for the at least one other container unit located on the target node is blocked.

[0086] In this embodiment, the target resource allocation component can establish a communication connection with the node agent and assist the node agent in pre-allocating at least one set of huge page memory files corresponding to multiple NUMA nodes on the target node for the Pod. Furthermore, when the container orchestration engine does not support allocating huge page memory resources to the Pod at the granularity of NUMA nodes, it assists the node agent in achieving the pre-allocation of huge page memory resources at the granularity of NUMA nodes, facilitating the containerized deployment of the target application in the Pod and meeting the high-performance processing requirements of the target application.

[0087] Figure 7 is a flowchart illustrating the execution of a resource processing method provided in an exemplary embodiment of the present disclosure on the target application side. The method may include the steps shown in Figure 7:

[0088] Step 701: In response to the startup operation of the target application in the target container unit, determine the directory of at least one set of huge page memory files corresponding to at least one non-uniform memory node allocated to the target container unit; wherein, the at least one set of huge page memory files is pre-allocated to the target container unit by the node agent calling the target resource allocation component.

[0089] Step 702: Load the at least one set of large page memory files according to the directory of the at least one set of large page memory files, and map the at least one set of large page memory files to the virtual address space corresponding to the target application, so as to access the at least one set of large page memory files in the virtual address space based on a non-uniform memory access mechanism.

[0090] Optionally, determining the directory of at least one set of huge page memory files corresponding to multiple non-uniform memory nodes allocated to the target container unit includes: within the target container unit, determining the huge page memory directory corresponding to each of the at least one non-uniform memory nodes; and reading the directory of at least one set of huge page memory files corresponding to each of the at least one non-uniform memory nodes according to the huge page memory directory corresponding to each of the at least one non-uniform memory nodes.

[0091] In this embodiment, after the target application is containerized and deployed, it directly determines at least one set of large page memory files by reading the directory of at least one set of large page memory files corresponding to multiple non-uniform memory nodes allocated to the target container unit. After mapping at least one set of large page memory files to the virtual address space, the large page memory resources can be used. Compared with the traditional MMAP system call method, in the solution provided by this embodiment, at least one set of large page memory files has already been created. The target application does not need to apply for and create large page memory resources through MMAP system calls; it only needs to map the created large page memory files, thereby greatly improving the process startup speed of the target application. In particular, the more large page memory resources requested by the Pod, the more the process startup time of the target application is saved compared to the process startup time of the traditional solution. In some embodiments, when the size of the large page memory resources requested by the Pod increases by a multiple, the process startup time within the Pod can still be kept within 1 second, greatly improving the process startup efficiency. In some optional embodiments, compared with the large page memory resource allocation scheme based on control groups, the process startup efficiency within the Pod can be improved by about 60 times.

[0092] The execution subject of each step in the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 501 to 503 can be device A; or the execution subject of steps 501 and 502 can be device A, and the execution subject of step 503 can be device B; and so on.

[0093] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 501, 502, etc., are used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. The terms "first," "second," etc., used herein are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0094] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0095] Figure 8 illustrates a structural diagram of an electronic device provided in an exemplary embodiment of the present disclosure. As shown in Figure 8, the electronic device includes a memory 801, a processor 802, and a communication component 803.

[0096] Memory 801 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device.

[0097] In some exemplary embodiments, the electronic device shown in FIG8 can be used to execute a resource allocation method. A processor 802 is coupled to a memory 801 and is used to execute a computer program corresponding to a node agent in the memory 801, for the following purposes: obtaining a resource allocation request from a target container unit, the target container unit being used to run a target application that accesses memory resources based on a non-uniform memory access mechanism, the target node where the target container unit is located including multiple non-uniform memory nodes; invoking a target resource allocation component to pre-allocate at least one set of large page memory files according to the resource allocation request, the at least one set of large page memory files corresponding to at least one non-uniform memory node among the multiple non-uniform memory nodes; allocating the at least one set of large page memory files to the target container unit according to the directory of the at least one set of large page memory files, the target application being used to directly load the at least one set of large page memory files and access the at least one set of large page memory files using the non-uniform memory access mechanism.

[0098] Optionally, when the processor 802 calls the target resource allocation component to pre-allocate at least one set of large page memory files according to the resource allocation request, it is specifically configured to: parse the resource allocation request to obtain the declaration information of the container storage interface; if the declaration information contains the identification information of the target resource allocation component, then call the target resource allocation component to pre-allocate the at least one set of large page memory files according to the resource allocation request.

[0099] Optionally, when the processor 802 allocates the at least one set of large page memory files to the target container unit according to the directory of the at least one set of large page memory files, it specifically performs the following steps: within the target container unit, it determines the large page memory directory corresponding to each of the at least one non-uniform memory nodes; it calls the container storage interface to mount the directory of the at least one set of large page memory files to the large page memory directory corresponding to each of the at least one non-uniform memory nodes according to the correspondence between the at least one set of large page memory files and the at least one non-uniform memory node.

[0100] In this implementation, after obtaining the resource allocation request from the Pod, the node agent can invoke the target resource allocation component to pre-allocate at least one set of huge page memory files corresponding to multiple NUMA nodes on the target node for the Pod. After obtaining the directory of at least one set of huge page memory files, the node agent can allocate these files to the Pod, enabling the target application running in the Pod to access these files on the target node based on the NUMA access mechanism. Furthermore, even when the container orchestration engine does not support allocating huge page memory resources to the Pod at the NUMA node granularity, the target resource allocation component enables the pre-allocation of huge page memory resources at the NUMA node granularity, facilitating the containerized deployment of the target application within the Pod and meeting the high-performance processing requirements of the target application.

[0101] In some other exemplary embodiments, the electronic device shown in FIG8 can be used to execute a resource allocation method, wherein a processor 802 is coupled to a memory 801 and is used to execute a computer program corresponding to a target resource allocation component in the memory 801, for: receiving a resource allocation request from a target container unit sent by a node agent, the target container unit being used to run a target application that accesses memory resources based on a non-uniform memory access mechanism, the target node where the target container unit is located including multiple non-uniform memory nodes; pre-allocating at least one set of large page memory files according to the resource allocation request, the at least one set of large page memory files corresponding to at least one non-uniform memory node among the multiple non-uniform memory nodes; and returning the directory of the at least one set of large page memory files to the node agent, the directory of the at least one set of large page memory files being used to enable the node agent to allocate the at least one set of large page memory files to the target container unit.

[0102] Optionally, when the processor 802 pre-allocates at least one set of large page memory files according to the resource allocation request, it specifically performs the following steps: Based on the resource allocation request, it determines at least one non-uniform memory node from the plurality of non-uniform memory nodes to which large page memory resources are to be allocated; in the physical memory of the target node, it pre-allocates at least one local physical memory corresponding to the at least one non-uniform memory node for the target container unit, wherein the addresses of any local physical memory are contiguous; and creates large page memory files in the local physical memory pre-allocated to the at least one non-uniform memory node, respectively, to obtain the at least one set of large page memory files.

[0103] Optionally, the processor 802 is further configured to: during the process of pre-allocating the at least one contiguous local physical memory for the target container unit, if there is a pending resource allocation request for at least one other container unit, the at least one other container unit located on the target node, then block the resource allocation request for the at least one other container unit.

[0104] In this implementation, the target resource allocation component can establish a communication connection with the node agent and assist the node agent in pre-allocating at least one set of huge page memory files corresponding to multiple NUMA nodes on the target node for the Pod. Furthermore, even when the container orchestration engine does not support allocating huge page memory resources to the Pod at the NUMA node granularity, it assists the node agent in achieving the pre-allocation of huge page memory resources at the NUMA node granularity, facilitating the containerized deployment of the target application within the Pod and meeting the high-performance processing requirements of the target application.

[0105] In some further exemplary embodiments, the electronic device shown in FIG8 can be used to execute a resource processing method, wherein a processor 802 is coupled to a memory 801 and is used to execute a computer program corresponding to a target application in the memory 801, for: responding to a startup operation of a target application in a target container unit, determining a directory of at least one set of large page memory files allocated to the target container unit and corresponding to at least one non-uniform memory node; wherein the at least one set of large page memory files is pre-allocated to the target container unit using a resource allocation method provided in embodiments of this disclosure; loading the at least one set of large page memory files according to the directory of the at least one set of large page memory files, and mapping the at least one set of large page memory files to a virtual address space corresponding to the target application, so as to access the at least one set of large page memory files in the virtual address space based on a non-uniform memory access mechanism.

[0106] Optionally, when determining the directories of at least one set of huge page memory files corresponding to multiple non-uniform memory nodes allocated to the target container unit, the processor 802 is specifically configured to: determine the huge page memory directories corresponding to each of the at least one non-uniform memory nodes within the target container unit; and read the directories of at least one set of huge page memory files corresponding to the at least one non-uniform memory node according to the huge page memory directories corresponding to each of the at least one non-uniform memory nodes.

[0107] In this implementation, after the target application is containerized and deployed, it directly determines at least one set of large page memory files by reading the directory of at least one set of large page memory files corresponding to multiple non-uniform memory nodes allocated to the target container unit. After mapping at least one set of large page memory files to the virtual address space, the large page memory resources can be used. Compared to the traditional MMAP system call method, in the solution provided in this embodiment, at least one set of large page memory files has already been created. The target application does not need to request and create large page memory resources through MMAP system calls; it only needs to map the created large page memory files, thereby greatly improving the process startup speed of the target application. In particular, the more large page memory resources requested by the Pod, the more the process startup time of the target application is saved compared to the process startup time of the traditional solution. When the size of the large page memory resources requested by the Pod increases by a factor of two, the process startup time within the Pod can still be kept within 1 second, greatly improving the process startup efficiency.

[0108] Furthermore, as shown in Figure 8, the electronic device also includes other components such as a power supply component 804, a display component 805, and an audio component 806. Figure 8 schematically shows only some components and does not imply that the electronic device only includes the components shown in Figure 8. In Figure 8, the components within the dashed boxes are optional, not mandatory, and their specific inclusion depends on the product form of the electronic device. The electronic device of this embodiment can be implemented as a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or as a server-side device such as a conventional server, cloud server, or server array. If the electronic device of this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include the components within the dashed boxes in Figure 8; if the electronic device of this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, it may not include the components within the dashed boxes in Figure 8.

[0109] The memory 801 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0110] The communication component 803 is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as Wi-Fi, 2G (e.g., Global System for Mobile Communications (GSM)), 3G (e.g., Wideband Code Division Multiple Access (WCDMA), 4G (e.g., Long Term Evolution (LTE)), 4G+ (e.g., LTE-Advanced (LTE-A)), or 5G (5th Generation Mobile Communication Technology), or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component may be implemented based on Near Field Communication (NFC), Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0111] The power supply component 804 is used to provide power to various components of the device in which the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component is located.

[0112] The display component includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action, but also the duration and pressure associated with the touch or swipe operation.

[0113] An audio component may be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0114] Accordingly, this disclosure also provides a computer-readable storage medium storing a computer program, which, when executed, can perform the steps that can be executed by an electronic device in the above method embodiments.

[0115] This disclosure also provides a computer program product, including: a computer program / instructions, which, when executed by a processor, can implement the steps in the method provided in this disclosure.

[0116] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM (Compact Disc Read-Only Memory), optical storage, etc.) containing computer-usable program code.

[0117] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0118] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0119] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0120] In a typical configuration, a computing device includes one or more processors (Central Processing Units, CPUs), input / output interfaces, network interfaces, and memory.

[0121] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0122] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0123] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes those elements, as well as other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, an element defined by the phrase “comprising one…” does not exclude the presence of other identical elements in the process, method, product, or apparatus that includes said element.

[0124] The above description is merely an embodiment of this disclosure and is not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A resource allocation method, comprising: Obtain the resource allocation request of the target container unit, which is used to run the target application that accesses memory resources based on a non-uniform memory access mechanism, and the target node where the target container unit is located includes multiple non-uniform memory nodes; Invoke the target resource allocation component to pre-allocate at least one set of large page memory files according to the resource allocation request. The at least one set of large page memory files corresponds to at least one non-uniform memory node among the plurality of non-uniform memory nodes. Based on the directory of the at least one set of large page memory files, the at least one set of large page memory files are allocated to the target container unit. The target application is used to directly load the at least one set of large page memory files and access the at least one set of large page memory files using the non-uniform memory access mechanism.

2. The method according to claim 1, wherein, Invoke the target resource allocation component to pre-allocate at least one set of large page memory files according to the resource allocation request, including: The resource allocation request is parsed to obtain the declaration information of the container storage interface; If the declaration information contains the identification information of the target resource allocation component, then the target resource allocation component is invoked to pre-allocate the at least one set of large page memory files according to the resource allocation request.

3. The method according to claim 1, wherein, Allocating the at least one set of large page memory files to the target container unit according to the directory of the at least one set of large page memory files includes: Within the target container unit, determine the large page memory directory corresponding to each of the at least one non-uniform memory node; The container storage interface is invoked, and based on the correspondence between the at least one set of large page memory files and the at least one non-uniform memory node, the directory of the at least one set of large page memory files is mounted to the large page memory directory corresponding to each of the at least one non-uniform memory nodes.

4. The method according to claim 1, wherein, The target resource allocation component runs on the target node.

5. A resource allocation method, comprising: The receiving node agent sends a resource allocation request for a target container unit, which is used to run a target application that accesses memory resources based on a non-uniform memory access mechanism. The target node where the target container unit is located includes multiple non-uniform memory nodes. According to the resource allocation request, at least one set of large page memory files is pre-allocated, and the at least one set of large page memory files corresponds to at least one non-uniform memory node among the plurality of non-uniform memory nodes; The directory of the at least one set of large page memory files is returned to the node agent, and the directory of the at least one set of large page memory files is used to enable the node agent to allocate the at least one set of large page memory files to the target container unit.

6. The method according to claim 5, wherein, Based on the resource allocation request, at least one set of large page memory files is pre-allocated, including: Based on the resource allocation request, at least one non-uniform memory node to be allocated large page memory resources is determined from the plurality of non-uniform memory nodes; In the physical memory of the target node, at least one local physical memory corresponding to the at least one non-uniform memory node is pre-allocated for the target container unit, and the addresses of any local physical memory are contiguous; Large page memory files are created in the local physical memory pre-allocated to the at least one non-uniform memory node to obtain the at least one set of large page memory files.

7. The method according to claim 6, wherein, Also includes: In the process of pre-allocating at least one contiguous local physical memory to the target container unit, if there is a pending resource allocation request for at least one other container unit located on the target node, the resource allocation request for the at least one other container unit is blocked.

8. The method according to claim 5, wherein, The node agent is used to register the driver through the identification module in the target resource allocation component.

9. The method according to claim 5, wherein, The huge page file system in the kernel space of the target node is communicatively connected to the huge page memory management module in the target resource allocation component.

10. A resource processing method, comprising: In response to a startup operation of a target application in a target container unit, a directory of at least one set of massive page memory files corresponding to at least one non-uniform memory node is determined for the target container unit; wherein the at least one set of massive page memory files is pre-allocated to the target container unit using the method described in any one of claims 1-9; Based on the directory of the at least one set of large page memory files, load the at least one set of large page memory files and map the at least one set of large page memory files to the virtual address space corresponding to the target application, so as to access the at least one set of large page memory files in the virtual address space based on a non-uniform memory access mechanism.

11. The method according to claim 10, wherein, Determine the directories of at least one set of large page memory files corresponding to multiple non-uniform memory nodes allocated to the target container unit, including: Within the target container unit, determine the large page memory directory corresponding to each of the at least one non-uniform memory node; Based on the large page memory directory corresponding to each of the at least one non-uniform memory nodes, read the directory of at least one set of large page memory files corresponding to the at least one non-uniform memory node.

12. A resource allocation system, wherein, include: Scheduler, target node, and target resource allocation component; The target node runs a node agent and a target container unit, and the target container unit runs the target application. The target node includes multiple non-uniform memory nodes, and the target application accesses memory resources based on a non-uniform memory access mechanism. The scheduler is configured to: respond to the deployment request of the target container unit and schedule the target container unit to the target node; The node agent is used to: obtain the resource allocation request of the target container unit; invoke the target resource allocation component to pre-allocate at least one set of large page memory files according to the resource allocation request, wherein the at least one set of large page memory files corresponds to at least one non-unified memory node among the plurality of non-unified memory nodes; and allocate the at least one set of large page memory files to the target container unit according to the directory of the at least one set of large page memory files. The target resource allocation component is used to: receive the resource allocation request, pre-allocate at least one set of huge page memory files corresponding to the at least one non-uniform memory node, and return the directory of the at least one set of huge page memory files to the node agent; The target application is configured to: respond to the launch operation of the target application, determine the directory of at least one set of huge page memory files allocated to the target container unit and corresponding to the at least one non-uniform memory node; load the at least one set of huge page memory files according to the directory of the at least one set of huge page memory files, and map the at least one set of huge page memory files to the virtual address space corresponding to the target application, so as to access the at least one set of huge page memory files in the virtual address space based on the non-uniform memory access mechanism.

13. The resource allocation system according to claim 12, wherein, The node agent is also used to perform the following steps: The resource allocation request is parsed to obtain the declaration information of the container storage interface; If the declaration information contains the identification information of the target resource allocation component, then the target resource allocation component is invoked to pre-allocate the at least one set of large page memory files according to the resource allocation request.

14. The resource allocation system according to claim 12, wherein, The node agent is also used to perform the following steps: Within the target container unit, determine the large page memory directory corresponding to each of the at least one non-uniform memory node; The container storage interface is invoked, and based on the correspondence between the at least one set of large page memory files and the at least one non-uniform memory node, the directory of the at least one set of large page memory files is mounted to the large page memory directory corresponding to each of the at least one non-uniform memory nodes.

15. The resource allocation system according to claim 12, wherein, The target resource allocation component is also used to perform the following steps: Based on the resource allocation request, at least one non-uniform memory node to be allocated large page memory resources is determined from the plurality of non-uniform memory nodes; In the physical memory of the target node, at least one local physical memory corresponding to the at least one non-uniform memory node is pre-allocated for the target container unit, and the addresses of any local physical memory are contiguous; Large page memory files are created in the local physical memory pre-allocated to the at least one non-uniform memory node to obtain the at least one set of large page memory files.

16. The resource allocation system according to claim 15, wherein, The target resource allocation component is also used to perform the following steps: In the process of pre-allocating at least one contiguous local physical memory to the target container unit, if there is a pending resource allocation request for at least one other container unit located on the target node, the resource allocation request for the at least one other container unit is blocked.

17. The resource allocation system according to claim 12, wherein, The target application is also used to perform the following steps: Within the target container unit, determine the large page memory directory corresponding to each of the at least one non-uniform memory node; Based on the large page memory directory corresponding to each of the at least one non-uniform memory nodes, read the directory of at least one set of large page memory files corresponding to the at least one non-uniform memory node.

18. An electronic device comprising: Memory and processor; The memory is used to store one or more computer instructions; The processor is configured to execute one or more computer instructions for performing the steps of the method according to any one of claims 1-11.

19. A computer-readable storage medium storing a computer program, which, when executed by a processor, enables the implementation of the steps of the method according to any one of claims 1-11.

20. A computer program product comprising: A computer program / instruction that, when executed by a processor, enables the implementation of the steps in the method described in any one of claims 1-11.

Images