Memory strategy management method and device

Abstract

The embodiment of the invention provides a memory strategy management method and device, and relates to the technical field of computers.The method comprises the steps that a kernel of a multi-memory-node system receives a strategy setting request sent by a first process through preset system calling, and the strategy setting request comprises strategy setting parameters and an identifier of a second process; verifying the permission and strategy setting parameters of the first process and the second process; if it is determined through verification that the first process has the permission to modify the memory strategy, the strategy setting parameters are legal, and the second process exists, the memory strategy of the second process is processed according to the strategy setting parameters. According to the scheme, the problems that in the prior art, cross-process memory strategy management operation is complex, flexibility and adaptability are insufficient, and extra safety risks, performance fluctuation and instability are possibly introduced can be solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a memory strategy management method and apparatus. Background Technology

[0002] With the widespread adoption of multi-core, multi-processor servers and high-performance computing platforms, Non-Uniform Memory Access (NUMA) system architecture has become one of the mainstream solutions for improving the performance of multi-processor systems.

[0003] To fully leverage the performance advantages of the NUMA system architecture, Linux-based operating systems offer various memory strategies, including strict binding, priority node, interleaved allocation, and local priority. Processes (such as user applications) set their own memory strategies based on their workload characteristics through system calls such as memory region binding functions (e.g., mbind()) and process memory policy setting functions (e.g., set_mempolicy()), in order to allocate memory resources rationally within the NUMA system.

[0004] However, existing system calls only apply to the process that invoked the system call and lack direct access to other processes. Adjusting the memory policies of other processes requires intrusive methods such as API calls, code injection, and debugging. These methods are complex, lack flexibility and adaptability, and may introduce additional security risks, performance fluctuations, and instability. Summary of the Invention

[0005] The purpose of this application is to provide a memory policy management method and apparatus to solve the problems of complex cross-process memory policy management operations, insufficient flexibility and adaptability, and potential introduction of additional security risks, performance fluctuations, and instability in the prior art. The specific technical solution is as follows:

[0006] In a first aspect, embodiments of this application provide a memory policy management method applied to the kernel of a multi-memory node system, the method comprising:

[0007] The system receives a policy setting request sent by the first process via a preset system call. The policy setting request includes policy setting parameters and the identifier of the second process.

[0008] The permissions of the first process, the policy setting parameters, and the second process are verified.

[0009] If it is verified that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and the second process exists, then the memory policy of the second process is processed according to the policy setting parameters.

[0010] In some embodiments, the method further includes:

[0011] The system receives a query request sent by the first process through a virtual file system interface, the query request including the identifier of the second process.

[0012] Obtain the memory allocation status information of the second process;

[0013] The status information is returned to the first process through the virtual file system interface;

[0014] The step of receiving the policy setting request sent by the first process through a preset system call includes:

[0015] The virtual file system interface is used to invoke the preset system call to receive the policy setting request sent by the first process.

[0016] In some embodiments, the preset system call is a memory policy setting function, and the policy setting parameters include the target policy mode, the target node mask pointer, and the maximum number of bits in the node mask;

[0017] The step of processing the memory policy of the second process according to the parameter settings of the policy includes:

[0018] The target memory node pointed to by the target node mask pointer is determined based on the maximum number of bits in the node mask.

[0019] The second process is bound to the target memory node, and the memory policy of the second process is updated to the memory policy indicated by the target policy mode.

[0020] In some embodiments, the preset system call is a memory policy acquisition function, and the policy setting parameters include the maximum number of bits in the node mask, the target virtual address, and the query flag.

[0021] The step of processing the memory policy of the second process according to the parameter settings of the policy includes:

[0022] Based on the query flag and the maximum number of bits in the node mask, query the target memory node and target memory strategy corresponding to the target virtual address;

[0023] The target node mask pointer and the target memory policy are returned to the first process, wherein the target node mask pointer points to the queried target memory node.

[0024] In some embodiments, the preset system call is a home node setting function, and the policy setting parameters include the starting virtual address, the target address range length, and the home node identifier;

[0025] The step of processing the memory policy of the second process according to the parameter settings of the policy includes:

[0026] Based on the starting virtual address and the target address range length, the target address range corresponding to the second process is determined, wherein the starting address of the target address range is the starting virtual address, and the length of the target address range is the target address range length;

[0027] Bind the virtual memory region in the target address range to the memory node corresponding to the home node identifier, and update the memory policy of the target address range to the home node policy.

[0028] In some embodiments, the preset system call is a memory region binding function, and the policy setting parameters include the starting virtual address, the target address range length, the target policy mode, the target node mask pointer, the maximum number of bits in the node mask, and the configuration flag bits;

[0029] The step of processing the memory policy of the second process according to the parameter settings of the policy includes:

[0030] Based on the starting virtual address and the target address range length, the target address range corresponding to the second process is determined, wherein the starting address of the target address range is the starting virtual address, and the length of the target address range is the target address range length;

[0031] The target memory node pointed to by the target node mask pointer is determined based on the configuration flag bits and the maximum number of bits in the node mask;

[0032] Bind the virtual memory region in the target address range to the target memory node, and update the memory policy of the target address range to the memory policy indicated by the target policy mode.

[0033] Secondly, embodiments of this application provide a memory policy management device applied to the kernel of a multi-memory node system, the device comprising:

[0034] The first receiving module is used to receive a policy setting request sent by the first process through a preset system call. The policy setting request includes policy setting parameters and the identifier of the second process.

[0035] The verification module is used to verify the permissions of the first process, the policy setting parameters, and the second process;

[0036] The processing module is configured to, if it is verified that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and the second process exists, process the memory policy of the second process according to the policy setting parameters.

[0037] In some embodiments, the apparatus further includes:

[0038] The second receiving module is used to receive a query request sent by the first process through a virtual file system interface, wherein the query request includes the identifier of the second process;

[0039] The acquisition module is used to acquire the memory allocation status information of the second process;

[0040] The return module is used to return the status information to the first process through the virtual file system interface;

[0041] The first receiving module is specifically used to receive a policy setting request sent by the first process by calling the preset system call through the virtual file system interface.

[0042] In some embodiments, the preset system call is a memory policy setting function, and the policy setting parameters include the target policy mode, the target node mask pointer, and the maximum number of bits in the node mask;

[0043] The processing module is specifically used to determine the target memory node pointed to by the target node mask pointer based on the maximum number of bits in the node mask; bind the second process to the target memory node; and update the memory policy of the second process to the memory policy indicated by the target policy mode.

[0044] In some embodiments, the preset system call is a memory policy acquisition function, and the policy setting parameters include the maximum number of bits in the node mask, the target virtual address, and the query flag.

[0045] The processing module is specifically used to query the target memory node and target memory policy corresponding to the target virtual address based on the query flag and the maximum number of bits in the node mask; and to return the target node mask pointer and the target memory policy to the first process, wherein the target node mask pointer points to the queried target memory node.

[0046] In some embodiments, the preset system call is a home node setting function, and the policy setting parameters include the starting virtual address, the target address range length, and the home node identifier;

[0047] The processing module is specifically used to determine the target address range corresponding to the second process based on the starting virtual address and the target address range length, wherein the starting address of the target address range is the starting virtual address and the length of the target address range is the target address range length; bind the virtual memory region in the target address range to the memory node corresponding to the home node identifier; and update the memory policy of the target address range to the home node policy.

[0048] In some embodiments, the preset system call is a memory region binding function, and the policy setting parameters include the starting virtual address, the target address range length, the target policy mode, the target node mask pointer, the maximum number of bits in the node mask, and the configuration flag bits;

[0049] The processing module is specifically configured to: determine the target address range corresponding to the second process based on the starting virtual address and the target address range length, wherein the starting address of the target address range is the starting virtual address and the length of the target address range is the target address range length; determine the target memory node pointed to by the target node mask pointer based on the configuration flag bit and the maximum number of bits of the node mask; bind the virtual memory region in the target address range to the target memory node; and update the memory policy of the target address range to the memory policy indicated by the target policy mode.

[0050] Thirdly, embodiments of this application provide an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0051] Memory, used to store computer programs;

[0052] When the processor executes a program stored in memory, it implements any of the memory management strategies described above.

[0053] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the memory strategy management methods described above.

[0054] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the computer to execute any of the above-described memory strategy management methods.

[0055] Beneficial effects of the embodiments in this application:

[0056] The technical solution provided in this application's embodiments configures a preset system call in a multi-memory node system for implementing cross-process memory policy management. The preset system call serves as a cross-process policy read / write channel between kernel mode and user mode. During cross-process memory policy management, the first process uses the preset system call to pass policy setting parameters and the identifier of the second process (i.e., the target process) to the kernel. The kernel verifies that the first process has permission to modify the memory policy, that the policy setting parameters are valid, and that the second process exists. Based on the policy setting parameters, the kernel then queries and modifies the memory policy of the second process. This solution, through the preset system call, achieves cross-process memory policy management under successful security verification, overcoming the limitation in existing technologies where system calls can only operate on the process that calls the system call. It is simple to operate, offers better flexibility and adaptability, reduces introduced additional security risks and performance fluctuations, and improves system performance stability.

[0057] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

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

[0059] Figure 1 This is a schematic diagram of a first type of memory policy management method provided in an embodiment of this application;

[0060] Figure 2 This is a second flowchart illustrating the memory policy management method provided in an embodiment of this application.

[0061] Figure 3 A schematic diagram of the memory policy management process provided in an embodiment of this application;

[0062] Figure 4 A schematic diagram of the structure of a memory policy management device provided in an embodiment of this application;

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

[0064] 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 skilled in the art based on this application are within the scope of protection of this application.

[0065] For ease of understanding, the terms appearing in the embodiments of this application are explained below.

[0066] Non-Uniform Memory Access (NUMA) is a multiprocessor memory architecture design concept widely used in large servers and high-performance computing platforms sensitive to memory access latency. In a NUMA system architecture, the entire operating system consists of multiple NUMA nodes (i.e., memory nodes), each containing one or more processor cores and their associated local memory. Processor cores accessing local memory are much faster than accessing the memory of other NUMA nodes because cross-node access requires data transfer via interconnect links. This leads to differences in memory access latency and bandwidth performance, as well as resource contention between nodes. The advantage of the NUMA system architecture is that it allows different NUMA nodes to process their local data in parallel, reducing access conflicts, improving overall memory bandwidth and processing efficiency, and increasing total system throughput. However, it also places higher demands on software development, requiring optimization of scheduling and data layout strategies based on node topology. The NUMA system architecture evolved from Symmetric Multi-Processing (SMP) architecture and is widely used in multi-processor servers, virtualization environments, and memory-intensive computing tasks.

[0067] System calls are the sole method for user-space programs (i.e., processes) to access operating system kernel services, acting as an interface bridge between user mode and kernel mode. In most operating systems, such as Unix / Linux, system calls are exposed to the programming interface as functions. At the underlying level, they switch to kernel mode via software interrupts, trap instructions, or specific hardware mechanisms to perform privileged operations. Through system calls, user-space programs can perform a range of low-level operations that cannot be directly implemented by ordinary code, such as file operations, process control, memory management, network communication, and device access. System calls typically have fixed numbers and calling conventions. When the kernel receives a call request, it performs parameter checks, security verification, and error handling. Because system calls involve privilege level switching, their performance overhead is relatively high. Therefore, the kernel and compiler typically optimize the call path and provide a minimal set of interfaces to meet functional requirements.

[0068] The Process File System (procfs), also known as the / proc file system, is a virtual file system in Unix-like operating systems used to display runtime system kernel and process information. Its contents are not stored on disk but are dynamically generated by the kernel upon access. Procfs is an interface to kernel data structures, providing a mechanism to read system and process states in file form without directly invoking system calls. This allows access to a wealth of kernel information, such as Central Processing Unit (CPU) status, memory usage, process attributes, and kernel parameters. In procfs, each running process typically corresponds to a directory named after its process identifier (PID). This directory contains multiple virtual files reflecting the process's running status and resource usage. Besides monitoring, procfs also supports limited writability, allowing users to influence kernel parameters or process behavior by modifying virtual files. The advantages of procfs are intuitive access, a unified interface, and ease of scripting; however, it requires strict kernel control regarding performance and security to prevent unnecessary overhead or unauthorized operations.

[0069] Memory strategy: A set of rules or schemes used by the operating system to allocate memory resources, determining the selection, allocation method, and access priority of physical memory. In system architectures with multiple memory nodes (such as NUMA system architecture), the memory strategy determines the memory distribution of processes or threads across different memory nodes, thus significantly affecting access latency and bandwidth utilization. Common memory strategies include:

[0070] 1) Strict Binding Memory Policy: Restricts memory allocation to specified memory nodes;

[0071] 2) Preferred Node Memory Policy: Prefers a specific memory node, but uses other memory nodes when resources are insufficient;

[0072] 3) Interleaved Memory Policy: Distributes memory evenly across multiple memory nodes to balance the load;

[0073] 4) Local Node Memory Policy: Prioritizes the memory of the memory node to which the currently running CPU belongs.

[0074] 5) Home Node Memory Policy: Prioritize allocating physical memory to processes on this memory node.

[0075] Memory strategies are not necessarily static. Some operating systems support dynamic adjustments to strategies based on runtime conditions or scheduler decisions to adapt to task characteristics and system load. Choosing an appropriate memory strategy is a key step in achieving high performance and high resource utilization, especially in massively parallel computing and memory-intensive applications.

[0076] Home node: In a system architecture with multiple memory nodes, this is a parameter concept that defines the preferred memory node for a process or thread. When a home node is set, the operating system will prioritize allocating physical memory to the process on that node to maximize the locality of data and computational units, thereby reducing latency for cross-node access. This home node strategy is suitable for scenarios in NUMA systems where data needs to be located as close to the processor as possible, such as high-performance computing, big data analytics, or real-time processing applications. In the home node strategy, the home node is not an absolute constraint; when the preferred memory node cannot meet memory allocation requirements, the operating system can fall back to other memory nodes to avoid allocation failure. Related strategies include binding and interleaving allocation, which together provide the operating system with fine-grained memory allocation control. Properly setting the home node can effectively improve memory access performance and cache hit rate in multi-memory node systems, while reducing bandwidth pressure from interconnects.

[0077] To fully leverage the performance advantages of the NUMA system architecture, Linux-based operating systems offer various memory strategies, including strict binding, priority node, interleaved allocation, and local priority strategies, to allow processes (such as applications) to allocate memory resources rationally based on their workload characteristics. In Linux systems, these memory strategies can be set through system calls such as memory region binding functions (e.g., `mbind()`) and process memory policy setting functions (e.g., `set_mempolicy()`), or queried through certain interfaces exposed by procfs and the System File System (sysfs). Details are as follows:

[0078] (1) The process uses system calls to set memory policy.

[0079] Processes pass policy setting parameters to the kernel via system calls such as `mbind()` and `set_mempolicy()`, including the target policy mode and target node mask. Based on these parameters, the kernel binds the process to the memory node indicated by the target node mask according to the target policy mode, thus making the policy effective in the process's subsequent memory allocation paths.

[0080] For example, if a process passes policy settings parameters to the kernel, and the target policy mode is the priority node policy, and the memory nodes indicated by the target node mask include nodes 0 to 2, with node 0 being the preferred memory node, then the kernel can bind the process to nodes 0 to 2 according to the target policy mode. When allocating physical memory for the process later, physical memory will be allocated to the process from node 0 first.

[0081] (2) The process uses the virtual file system interface to query the memory allocation status information.

[0082] The kernel can virtually expose process memory allocation status information to user space (i.e., processes) through the procfs interface. This status information is generated directly by the kernel runtime and mapped to / proc / . <pid>This is implemented using the / directory method. For example, / proc / <pid>The ` / numa_maps` file outputs dynamic data such as node distribution, access counts, and policy flags for each Virtual Memory Area (VMA) based on the process's memory mapping table; ` / proc / ` <pid>The / status file also contains summary information related to NUMA, such as CPU affinity.

[0083] The contents of these procfs interfaces are read-only. Each time the kernel reads the contents, it generates a data stream based on the current process data structure (such as task_struct) and the real-time status of the relevant VMA, and returns it to the process, thereby ensuring the timeliness and consistency of the information.

[0084] The memory management strategy described above has the following drawbacks:

[0085] (1) System calls can only be applied to the process that called the system call. The kernel obtains the process's task_struct through the current macro and does not have the ability to directly access other processes.

[0086] (2) If it is necessary to adjust the memory policy of other processes, the process must call the system application programming interface (API) in the context of other processes, or use intrusive means such as injection or debugging to adjust the memory policy of other processes. This usually means that it is necessary to modify the code of other processes, restart other processes, load specific libraries, or use process tracing (ptrace) system call injection, which is complicated, lacks flexibility and adaptability, and may introduce additional security risks, performance fluctuations and instability.

[0087] (3) Virtual file system interfaces (such as procfs and sysfs interfaces) can only provide process memory allocation status information (such as NUMA allocation information) in read-only form and do not support modifying memory policies through writing. Therefore, processes cannot directly change their memory policies through the file system, which limits the application of scripting, batch processing, and automated operation and maintenance scenarios.

[0088] (4) System calls can set memory policies, but do not provide real-time status information such as memory allocation effects or hit rates; users need to obtain real-time status information through the virtual file system interface. The fragmented process of integrating information is not conducive to online closed-loop optimization.

[0089] To address the aforementioned problems, embodiments of this application provide a memory policy management method, such as... Figure 1 As shown, the method, applied to the kernel of a multi-memory node system, includes:

[0090] Step S101: Receive a policy setting request sent by the first process via a preset system call. The policy setting request includes policy setting parameters and the identifier of the second process.

[0091] Step S102: Verify the permissions and policy settings parameters of the first process and the second process;

[0092] Step S103: If it is verified that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and a second process exists, then the memory policy of the second process is processed according to the policy setting parameters.

[0093] The technical solution provided in this application's embodiments configures a preset system call in a multi-memory node system for implementing cross-process memory policy management. The preset system call serves as a cross-process policy read / write channel between kernel mode and user mode. During cross-process memory policy management, the first process uses the preset system call to pass policy setting parameters and the identifier of the second process (i.e., the target process) to the kernel. The kernel verifies that the first process has permission to modify the memory policy, that the policy setting parameters are valid, and that the second process exists. Based on the policy setting parameters, the kernel then queries and modifies the memory policy of the second process. This solution, through the preset system call, achieves cross-process memory policy management under successful security verification, overcoming the limitation in existing technologies where system calls can only operate on the process that calls the system call. It is simple to operate, offers better flexibility and adaptability, reduces introduced additional security risks and performance fluctuations, and improves system performance stability.

[0094] In this embodiment, the multi-memory node system can be a NUMA system or other operating systems that include multiple memory nodes. In a NUMA system, a memory node can also be called a NUMA node.

[0095] In step S101 above, the preset system call serves as a cross-process policy read / write channel between kernel mode and user mode. It is a unified, secure, low-overhead, low-latency, and controllable kernel interface. The preset system call is used to perform real-time, fine-tuning of the memory policy of any running process.

[0096] In this embodiment, the process refers to a user-space program. The first process is the caller, and the second process is the target process. The first and second processes can be any processes running on any node in a multi-memory node system; they can be the same or different. When the first and second processes are different, the memory policy management scheme provided in this embodiment is a cross-process memory policy management scheme.

[0097] In this embodiment, the first process invokes a preset system call to send a policy setting request to the kernel. The kernel then receives the policy setting request via the preset system call. The policy setting request includes policy setting parameters and an identifier for the second process. The specific information included in the policy setting parameters can be determined according to actual needs.

[0098] In step S102 above, when the kernel receives the policy setting request, it extracts the policy setting parameters and the identifier of the second process from the policy setting request, and then performs security verification, specifically: 1) verifying whether the first process has the permission to modify the memory policy; 2) verifying the legality of the policy setting parameters; 3) verifying whether the second process exists.

[0099] When the verification result indicates that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and a second process exists, the kernel executes step S103 to perform management operations such as querying and modifying the memory policy of the second process according to the policy setting parameters.

[0100] One way to verify whether the first process has permission to modify the memory policy is as follows: The kernel configures a list of processes with cross-process memory policy management permissions; if the first process is in this list, it has the permission to modify the memory policy; otherwise, it does not. Another way to verify this is: The kernel configures a list of processes without cross-process memory policy management permissions; if the first process is not in this list, it has the permission to modify the memory policy; otherwise, it does not. Other methods can also be used to verify this permission, and there are no limitations on these methods.

[0101] The validity of the verification strategy setting parameters can be verified by checking whether the parameter format is valid. For example, whether the maximum number of valid bits corresponding to the target node mask pointer is less than the maximum number of bits in the node mask. If it is less than the maximum number of bits in the node mask, the parameter is valid; if it is greater than or equal to the maximum number of bits in the node mask, the parameter is invalid.

[0102] The way to verify the existence of a second process is to verify whether a second process exists in the target memory node.

[0103] In the technical solution provided in this application embodiment, the kernel performs cross-process memory policy management operations only after the security verification is passed. This achieves dynamic management of cross-process memory policies while ensuring security and controllability, thereby improving the resource utilization and performance adaptability of multi-process systems under a multi-memory node architecture.

[0104] In this embodiment, the preset system calls may include, but are not limited to, memory policy setting functions, memory policy acquisition functions, owner node setting functions, and memory region binding functions, to adapt to dynamic memory policy management with multiple policy modes, multiple granularities, and cross-processes, further improving the resource utilization and performance adaptability of multi-process systems under a multi-memory node architecture. The preset system calls are described in detail below.

[0105] (1) The default system call is the memory policy setting function (such as set_pid_mempolicy). The policy setting parameters include the target policy mode (mode), the target node mask pointer (nodemask), and the maximum number of bits in the node mask (maxnode).

[0106] In this case, step S103 above can be: if it is verified that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and a second process exists, then the target memory node pointed to by the target node mask pointer is determined according to the maximum number of bits in the node mask; the second process is bound to the target memory node, and the memory policy of the second process is updated to the memory policy indicated by the target policy mode.

[0107] In this embodiment of the application, the memory policy setting function is used to set a global memory policy for the target process, specifying from which memory nodes the target process should allocate new memory requests in the future.

[0108] The first process calls the memory policy setting function, passing the target process identifier, policy mode, node mask pointer, and maximum number of bits in the node mask to the kernel to define the policy content. The memory policy setting function called by the first process can be represented as `set_pid_mempolicy(PID, mode, nodemask, maxnode)`.

[0109] The Target Process Identifier (PID) is the identifier of the target process (i.e., the second process) whose memory policy needs to be queried or modified.

[0110] The policy mode is the default memory policy applied to the entire target process, such as strict binding policy, priority node policy, interleaved allocation policy, local priority policy, etc.

[0111] The nodemask pointer is a pointer to a bitmask that specifies the target memory node. For example, each bit in the binary bitmap of a memory node corresponds to a memory node; bit 0 corresponds to memory node 0, bit 1 corresponds to memory node 1, and so on. If the nodemask pointer is 3, the corresponding binary bitmap is "0011". Since "1" is located at bits 0 and 1, memory node 0 (bit 0) and memory node 1 (bit 1) are both target memory nodes.

[0112] The maximum number of bits in the node mask (maxnode) is the largest valid node number in the node mask pointer (used to calculate the mask size).

[0113] The kernel receives parameters from the first process through the memory policy setting function. The target process identifier is the identifier of the second process, the policy mode in the passed parameters is the target policy mode, and the node mask pointer in the passed parameters is the target node mask pointer. Next, the kernel verifies the caller's (i.e., the first process's) permissions, verifies the validity of the parameters, and verifies the existence of the second process. If the verification is successful—meaning the first process has permission to modify the memory policy, the policy setting parameters are valid, and the second process exists—then the second process is allowed to operate. The kernel determines the target memory node pointed to by the target node mask pointer from among multiple memory nodes indicated by the maximum number of bits in the node mask. There may be one or more target memory nodes. The kernel binds the second process to the target memory node and updates the global memory policy information in the second process's memory management structure (e.g., `task_struct`) to the memory policy indicated by the target policy mode, making the new memory policy take effect immediately. Subsequently, when the second process requests new memory, the kernel allocates physical memory from the target memory node bound to the second process according to the memory policy indicated by the target policy mode.

[0114] The memory policy setting function allows management programs (such as the first process) to specify the overall memory allocation pattern of the target process across processes, thereby dynamically matching the hardware resource layout without modifying the business code and achieving process-level memory node / policy optimization binding.

[0115] (2) The preset system call is a memory policy retrieval function (such as get_pid_mempolicy). The policy setting parameters include the maximum number of bits in the node mask (maxnode), the target virtual address (addr), and the query flags (flags). In this embodiment, the policy setting parameters may also include the target policy mode (mode) and the target node mask pointer (nodemask). The target policy mode (mode) and the target node mask pointer (nodemask) are output parameters, while the maximum number of bits in the node mask (maxnode), the target virtual address (addr), and the query flags (flags) are input parameters, and a user space pointer policy is used to store the target policy mode.

[0116] In this case, step S103 above can be: if it is verified that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and a second process exists, then according to the query flag and the maximum number of bits in the node mask, query the target memory node corresponding to the target virtual address and the target memory policy; return the target node mask pointer and the target memory policy to the first process, with the target node mask pointer pointing to the queried target memory node.

[0117] In this embodiment of the application, the memory policy retrieval function is used to query the memory policy of the target process and its associated information.

[0118] The first process calls the memory policy acquisition function, passing the target process identifier, the maximum number of bits in the node mask, the target virtual address, and query flags to the kernel to define the policy content. The memory policy acquisition function called by the first process can be represented as `get_pid_mempolicy(PID, mode, nodemask, maxnode, addr, flags)`.

[0119] The Target Process Identifier (PID) is the identifier of the target process (i.e., the second process) whose memory policy needs to be queried or modified.

[0120] The strategy mode is the memory strategy found in the query, such as strict binding strategy, priority node strategy, interleaved allocation strategy, local priority strategy, etc.

[0121] The nodemask pointer is a pointer to a bitmask that specifies the target memory node.

[0122] The maximum number of bits in the node mask (maxnode) is the largest valid node number in the node mask pointer (used to calculate the mask size).

[0123] The virtual address (addr) is the virtual address being queried. If the virtual address is NULL, it indicates that the default memory policy of the target process is being queried.

[0124] The query flags control the query behavior. For example, the query flags can indicate the identifier of the memory node corresponding to the virtual address being queried; that is, the memory node corresponding to the virtual address is the memory node of the physical memory region containing the VMA containing the virtual address. The query flags can also indicate the memory policy corresponding to the virtual address (i.e., the memory policy of the VMA containing the virtual address); if the virtual address is NULL, the memory policy corresponding to the virtual address is the default memory policy of the target process; the query flags can also indicate the current memory node binding status or the status of the preferred memory node, etc.

[0125] The user-space pointer `policy` indicates the storage address in user space where the target memory policy is stored.

[0126] The kernel receives parameters from the first process through the memory policy acquisition function. The target process identifier is used as the identifier for the second process, and the virtual address in the passed parameters is the target virtual address. The kernel then verifies the caller's (the first process's) permissions, the validity of the parameters, and the existence of the second process. If the verification is successful, the second process is considered operable. Based on the query flags, the kernel searches for the memory node corresponding to the target virtual address (i.e., the target memory node) among multiple memory nodes indicated by the maximum number of bits in the node mask. There can be one or more target memory nodes, along with the corresponding memory policy (i.e., the target memory policy). The kernel converts the target memory node into a target node mask pointer and returns the queried target node mask pointer and target memory policy to the first process.

[0127] The memory policy retrieval function can not only provide policy mode and node set information, but also reflect the current memory binding or priority memory node status under a specified mode, providing data support for memory policy optimization and decision-making.

[0128] (3) The default system call is the home node setting function (such as set_pid_mempolicy_home_node). The policy setting parameters may include the starting virtual address (start addr), the target address range length (len), and the home node identifier (home_node). The policy setting parameters may also include additional flags.

[0129] In this case, step S103 can be as follows: If it is verified that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and a second process exists, then the target address range corresponding to the second process is determined according to the starting virtual address and the target address range length. The starting address of the target address range is the starting virtual address, and the length of the target address range is the target address range length. The virtual memory region in the target address range is bound to the memory node corresponding to the owner node identifier, and the memory policy of the target address range is updated to the owner node policy.

[0130] In this embodiment of the application, the home node setting function is used to set the home node (home_node) for memory access of a specified target process.

[0131] The first process calls the home node setting function, passing the target process ID, starting virtual address, address range length, home node ID, etc., to the kernel to define the policy content. The home node setting function called by the first process can be represented as `set_pid_mempolicy_home_node(PID, start addr, len, home_node, flags)`.

[0132] The Target Process Identifier (PID) is the identifier of the target process (i.e., the second process) whose memory policy needs to be queried or modified.

[0133] The starting virtual address (start addr) is the starting virtual address of the address range (i.e., the target address interval) to be queried.

[0134] The address range length (len) is the length of the address range (i.e., the target address interval) to be queried.

[0135] The home node identifier (home_node) is the identifier of the memory node to which the target process is bound; this memory node is the home node.

[0136] The additional flags are flags that control the binding behavior. In this embodiment, the additional flags can be 0.

[0137] The kernel receives parameters from the first process via the home node setting function. The target process identifier is the identifier of the second process, and the address range length in the passed parameters is the target address range length. The kernel then verifies the caller's (i.e., the first process's) permissions, the validity of the parameters, and the existence of the second process. If the verification is successful, the second process is considered operable. The kernel determines the target address range based on the starting virtual address and the target address range length. This target address range includes one or more Virtual Management Areas (VMAs). Each VMA in the target address range is bound to a home node, and the memory policy of each VMA in the target address range is updated to the home node policy in the second process's VMA management structure (e.g., `task_struct`). This ensures the new memory policy takes effect immediately, thus achieving optimized binding of memory nodes / policies at the specific memory region level.

[0138] The home node setting function can specify the optimal data storage location for performance-critical memory regions during the runtime of the target process, reducing cross-memory node access latency and improving cache hit rate.

[0139] (4) The default system call is the memory region binding function (such as pid_mbind). The policy setting parameters may include the starting virtual address (start addr), the target address range length (len), the target policy mode (mode), the target node mask pointer (nodemask), the maximum number of bits in the node mask (maxnode), and the configuration flags (flags).

[0140] In this case, step S103 can be as follows: If it is verified that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and a second process exists, then the target address range corresponding to the second process is determined according to the starting virtual address and the target address range length. The starting address of the target address range is the starting virtual address, and the length of the target address range is the target address range length. The target memory node pointed to by the target node mask pointer is determined according to the configuration flag bit and the maximum number of bits of the node mask. The virtual memory region in the target address range is bound to the target memory node, and the memory policy of the target address range is updated to the memory policy indicated by the target policy mode.

[0141] In this embodiment of the application, the memory region binding function is used to bind a memory node / policy to a specified VMA of a specified target process.

[0142] The first process calls the memory region binding function, passing the target process identifier, starting virtual address, address range length, policy mode node mask pointer, maximum number of bits in the node mask, configuration flags, etc., to the kernel to define the policy content. The memory region binding function called by the first process can be represented as `pid_mbind(PID, start addr, len, mode, nodemask, maxnode, flags)`.

[0143] The Target Process Identifier (PID) is the identifier of the target process (i.e., the second process) whose memory policy needs to be queried or modified.

[0144] The start virtual address (start addr) is the starting virtual address of the specified address range (i.e., the target address range).

[0145] The address range length (len) is the length of the specified address range (i.e., the target address interval).

[0146] A policy mode is a memory policy that applies to a specified address range (i.e., the target address range), such as strict binding policy, priority node policy, interleaved allocation policy, local priority policy, etc.

[0147] The nodemask pointer is a pointer to a bitmask that specifies the target memory node.

[0148] The maximum number of bits in the node mask (maxnode) is the maximum valid node number in the node mask pointer.

[0149] Configuration flags are used to control binding behavior. For example, configuration flags can indicate that an error should be returned when an existing memory page is not on the target memory node; configuration flags can also indicate that allocated memory pages should be migrated to the target memory node.

[0150] The kernel receives parameters from the first process via the memory region binding function. The target process identifier is the identifier of the second process; the address range length in the passed parameters is the target address range length; the policy mode in the passed parameters is the target policy mode; and the node mask pointer in the passed parameters is the target node mask pointer. Afterward, the kernel verifies the caller's (i.e., the first process's) permissions, verifies the validity of the parameters, and verifies the existence of the second process. If the verification is successful, meaning the first process has the authority to modify the memory policy, the policy settings are valid, and a second process exists, then the second process is operable. The kernel determines the target address range based on the starting virtual address and the length of the target address range. This target address range includes one or more Virtual Memory Access Modules (VMAs). Each VMA in the target address range is bound to its home node. In the second process's VMA management structure (such as task_struct), based on the configuration flags, the target memory node pointed to by the target node mask pointer is determined from among the multiple memory nodes indicated by the maximum number of bits in the node mask. Then, each VMA in the target address range is bound to the target memory node, and the memory policy of each VMA in the target address range is updated to the memory policy indicated by the target policy mode. This ensures that the new memory policy takes effect immediately, thereby achieving memory node / policy optimization binding at the specific memory region level and ensuring that subsequent memory accesses to a specific memory region are only completed on the specified target memory node.

[0151] Memory region binding functions provide an atomic, batch execution method for binding hot memory regions across processes, which helps improve memory access performance on critical paths.

[0152] Through the aforementioned preset system calls, multi-granularity memory policy control can be achieved at the entire process level and down to a specific VMA, adapting to dynamic memory policy management across multiple policy modes, multiple granularities, and cross-processes.

[0153] In some embodiments, the kernel can combine preset system calls with the virtual file system interface to jointly manage memory policies. The virtual file system interface can be either the procfs interface or the sysfs interface. Figure 2 As shown in the figure, this application embodiment also provides a memory policy management method applied to the kernel of a multi-memory node system. The method may include the following steps:

[0154] Step S201: Receive a query request sent by the first process through the virtual file system interface. The query request includes the identifier of the second process.

[0155] In this embodiment of the application, the virtual file system interface has a read function. The first process can call the virtual file system interface to send a query request to the kernel. The query request includes the identifier of the second process in order to read the memory allocation status information of the second process.

[0156] Step S202: Obtain the memory allocation status information of the second process;

[0157] After receiving the query request, the kernel obtains the identifier of the second process from the query request, and finds that the target object of this operation is the second process. Then, it reads the lock to obtain the policy object corresponding to the second process. The policy object includes memory allocation status information, such as the memory policy and associated information of the second process.

[0158] Step S203: Return status information to the first process through the virtual file system interface;

[0159] The kernel can convert policy objects into policy strings according to a preset format. The format of the policy string can be: <mode> [= <flag> ][: <nodelist>].in, <mode>The value can be the default strategy, local priority strategy, priority node strategy, strict binding strategy, interleaved allocation strategy, preferred node strategy, etc. <flag>The value can be static or relative. <nodelist>This is a compressed representation of the node set to improve readability. The node set is the set of target memory nodes pointed to by the node mask pointers mentioned above. In the compressed representation of the node set, commas can be used to separate segments, and hyphens "-" can be used to indicate continuous ranges. For example, the compressed representation of the node set can be (0-3,5), which indicates memory node 0, memory node 1, memory node 2, memory node 3, and memory node 5.

[0160] The kernel returns the policy string (i.e., the memory allocation status information of the second process) to the first process through the virtual file system interface.

[0161] In this embodiment, the policy string is terminated with a null character, and newline characters are added to the policy string as much as possible to further improve readability. To avoid the policy string occupying excessive cache space, a maximum length limit (MPOL_STR_SIZE) can be specified in the multi-memory node system to limit the policy string.

[0162] Step S204: Call a preset system call through the virtual file system interface to receive the policy setting request sent by the first process.

[0163] The first process, based on the memory allocation status information of the second process provided by the kernel, invokes a preset system call through the virtual file system interface to pass a policy setting request to the kernel. The policy setting parameters in this request can be in the following format: <mode> [= <flag> ][: <nodelist>The kernel can use policy settings to remove end-of-line control characters and follow the rules. <mode> [= <flag> ][: <nodelist>The system parses the policy setting parameters in the format of [] to obtain the policy object, such as the target policy mode, target node mask pointer, and maximum number of bits of the node mask, and then executes the following steps S205 and S206 to complete memory policy management.

[0164] In this embodiment of the application, when the kernel obtains the policy object, it can also save the user's original node mask to support subsequent "relative / static" rebinding semantics.

[0165] Step S205: Verify the permissions and policy settings parameters of the first process and the second process;

[0166] Step S206: If it is verified that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and a second process exists, then the memory policy of the second process is processed according to the policy setting parameters.

[0167] Steps S205 and S206 are the same as steps S102 and S103 above, and will not be repeated here.

[0168] When the memory policy of the second process is successfully processed, the kernel can return a write success message to the first process; if the resolution policy setting parameters fail, or there is insufficient permission or access error, the kernel can return the corresponding error code to the first process.

[0169] In the technical solution provided in this application embodiment, a writable interface is introduced into the virtual file system interface, enabling user-mode processes to perform write operations through the virtual file system interface (such as the first process passing a policy setting request to the kernel as mentioned above), complete policy adjustment, and facilitate scripting and batch operations.

[0170] In addition, the virtual file system interface supports both policy reading and setting, which can perform memory policy adjustments while obtaining real-time status information of memory nodes, facilitating online closed-loop optimization by automated scheduling systems.

[0171] The following is combined with Figure 3 The memory policy management process shown illustrates the memory policy management method provided in the embodiments of this application.

[0172] An automated management interface is established between user space and kernel space. This interface includes the aforementioned preset system calls and virtual file system interfaces (such as the procfs interface). Furthermore, a permission / security mechanism is configured in the multi-memory node system to perform security verification on policy setting parameters and target process identifiers.

[0173] The operations and maintenance personnel or operations and maintenance tools / scripts start a process that calls preset system calls and virtual file system interfaces in the automated management interface to read or set memory policies. The kernel performs security verification based on permission / security mechanisms, and accesses hardware resources such as CPU and memory only if the security verification is successful.

[0174] In the technical solution provided in this application embodiment, a cross-process management mechanism is built at the kernel layer that can safely and dynamically perform memory policy reading and modification on other processes. The core of this mechanism is to add system calls that support the target process in the kernel and combine them with the newly added writable function in the virtual file system interface to provide a unified read and write entry point for user space, so that policy state acquisition and modification operations can be completed in the same channel.

[0175] In addition, the virtual file system interface provided in this application not only supports various memory strategies and node set parameters such as strict binding strategy, priority node strategy, staggered allocation strategy, and local priority strategy, but also allows for multi-granular control at the entire process level and down to specific virtual memory regions. This enables flexible switching of memory strategies during process execution to adapt to different load stages and performance optimization needs.

[0176] Furthermore, the virtual file system interface can collect memory access and usage status in real time and simultaneously issue policy adjustments, realizing a closed-loop linkage between monitoring and configuration. Strict permission authentication and access control are introduced in the kernel mode to ensure the security and controllability of cross-process policy adjustments.

[0177] Corresponding to the memory policy management method described above, this application also provides a memory policy management device, such as... Figure 4 As shown, the kernel is applied to a multi-memory node system, and the device includes:

[0178] The first receiving module 401 is used to receive a policy setting request sent by the first process through a preset system call. The policy setting request includes policy setting parameters and the identifier of the second process.

[0179] The verification module 402 is used to verify the permissions and policy setting parameters of the first process and the second process.

[0180] The processing module 403 is used to process the memory policy of the second process according to the policy setting parameters if it is verified that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and a second process exists.

[0181] In some embodiments, the memory policy management device further includes:

[0182] The second receiving module is used to receive a query request sent by the first process through a virtual file system interface. The query request includes the identifier of the second process.

[0183] The acquisition module is used to obtain the memory allocation status information of the second process.

[0184] The return module is used to return status information to the first process through the virtual file system interface;

[0185] The first receiving module 401 is specifically used to receive the policy setting request sent by the first process by calling a preset system call through the virtual file system interface.

[0186] In some embodiments, the preset system call is a memory policy setting function, and the policy setting parameters include the target policy mode, the target node mask pointer, and the maximum number of bits in the node mask;

[0187] The processing module 403 is specifically used to determine the target memory node pointed to by the target node mask pointer based on the maximum number of bits in the node mask; bind the second process to the target memory node; and update the memory policy of the second process to the memory policy indicated by the target policy mode.

[0188] In some embodiments, the preset system call is a memory policy retrieval function, and the policy setting parameters include the maximum number of bits in the node mask, the target virtual address, and the query flag.

[0189] The processing module 403 is specifically used to query the target memory node and target memory policy corresponding to the target virtual address based on the query flag and the maximum number of bits in the node mask; and to return the target node mask pointer and target memory policy to the first process, with the target node mask pointer pointing to the queried target memory node.

[0190] In some embodiments, the preset system call is the home node setting function, and the policy setting parameters include the starting virtual address, the target address range length, and the home node identifier;

[0191] The processing module 403 is specifically used to determine the target address range corresponding to the second process based on the starting virtual address and the target address range length. The starting address of the target address range is the starting virtual address, and the length of the target address range is the target address range length. The module binds the virtual memory region in the target address range to the memory node corresponding to the owner node identifier, and updates the memory policy of the target address range to the owner node policy.

[0192] In some embodiments, the preset system call is a memory region binding function, and the policy setting parameters include the starting virtual address, the target address range length, the target policy mode, the target node mask pointer, the maximum number of bits in the node mask, and the configuration flag bits;

[0193] The processing module 403 is specifically used to determine the target address range corresponding to the second process based on the starting virtual address and the length of the target address range, wherein the starting address of the target address range is the starting virtual address and the length of the target address range is the length of the target address range; determine the target memory node pointed to by the target node mask pointer based on the configuration flag bits and the maximum number of bits of the node mask; bind the virtual memory region in the target address range to the target memory node; and update the memory policy of the target address range to the memory policy indicated by the target policy mode.

[0194] The technical solution provided in this application's embodiments configures a preset system call in a multi-memory node system for implementing cross-process memory policy management. The preset system call serves as a cross-process policy read / write channel between kernel mode and user mode. During cross-process memory policy management, the first process uses the preset system call to pass policy setting parameters and the identifier of the second process (i.e., the target process) to the kernel. The kernel verifies that the first process has permission to modify the memory policy, that the policy setting parameters are valid, and that the second process exists. Based on the policy setting parameters, the kernel then queries and modifies the memory policy of the second process. This solution, through the preset system call, achieves cross-process memory policy management under successful security verification, overcoming the limitation in existing technologies where system calls can only operate on the process that calls the system call. It is simple to operate, offers better flexibility and adaptability, reduces introduced additional security risks and performance fluctuations, and improves system performance stability.

[0195] This application also provides an electronic device, such as... Figure 5 As shown, it includes a processor 501, a communication interface 502, a memory 503, and a communication bus 504, wherein the processor 501, the communication interface 502, and the memory 503 communicate with each other through the communication bus 504.

[0196] Memory 503 is used to store computer programs;

[0197] The processor 501, when executing a program stored in the memory 503, implements any of the above memory management strategies.

[0198] The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0199] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0200] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0201] The processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0202] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements any of the memory strategy management methods described above.

[0203] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the memory strategy management methods described above.

[0204] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0205] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or 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. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0206] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, electronic devices, storage media, and program products are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0207] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.< / nodelist> < / flag> < / mode> < / nodelist> < / flag> < / mode> < / nodelist> < / flag> < / mode> < / nodelist> < / flag> < / mode> < / pid> < / pid> < / pid>

Claims

1. A memory policy management method, characterized by, The method, applied to the kernel of a multi-memory node system, includes: The system receives a policy setting request sent by the first process via a preset system call. The policy setting request includes policy setting parameters and the identifier of the second process. The permissions of the first process, the policy setting parameters, and the second process are verified. If it is verified that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and the second process exists, then the memory policy of the second process is processed according to the policy setting parameters.

2. The method of claim 1, wherein, The method further includes: The system receives a query request sent by the first process through a virtual file system interface, the query request including the identifier of the second process. Obtain the memory allocation status information of the second process; The status information is returned to the first process through the virtual file system interface; The step of receiving the policy setting request sent by the first process through a preset system call includes: The virtual file system interface is used to invoke the preset system call to receive the policy setting request sent by the first process.

3. The method according to claim 1 or 2, characterized in that, The preset system call is a memory policy setting function, and the policy setting parameters include the target policy mode, the target node mask pointer, and the maximum number of bits in the node mask. The step of processing the memory policy of the second process according to the parameter settings of the policy includes: The target memory node pointed to by the target node mask pointer is determined based on the maximum number of bits in the node mask. The second process is bound to the target memory node, and the memory policy of the second process is updated to the memory policy indicated by the target policy mode.

4. The method according to claim 1 or 2, characterized in that, The preset system call is a memory policy acquisition function, and the policy setting parameters include the maximum number of bits in the node mask, the target virtual address, and the query flag. The step of processing the memory policy of the second process according to the parameter settings of the policy includes: Based on the query flag and the maximum number of bits in the node mask, query the target memory node and target memory strategy corresponding to the target virtual address; The target node mask pointer and the target memory policy are returned to the first process, wherein the target node mask pointer points to the queried target memory node.

5. The method according to claim 1 or 2, characterized in that, The preset system call is the home node setting function, and the policy setting parameters include the starting virtual address, the target address range length, and the home node identifier; The step of processing the memory policy of the second process according to the parameter settings of the policy includes: Based on the starting virtual address and the target address range length, the target address range corresponding to the second process is determined, wherein the starting address of the target address range is the starting virtual address, and the length of the target address range is the target address range length; Bind the virtual memory region in the target address range to the memory node corresponding to the home node identifier, and update the memory policy of the target address range to the home node policy.

6. The method according to claim 1 or 2, characterized in that, The preset system call is a memory region binding function, and the policy setting parameters include the starting virtual address, the target address range length, the target policy mode, the target node mask pointer, the maximum number of bits in the node mask, and the configuration flag bits; The step of processing the memory policy of the second process according to the parameter settings of the policy includes: Based on the starting virtual address and the target address range length, the target address range corresponding to the second process is determined, wherein the starting address of the target address range is the starting virtual address, and the length of the target address range is the target address range length; The target memory node pointed to by the target node mask pointer is determined based on the configuration flag bits and the maximum number of bits in the node mask; Bind the virtual memory region in the target address range to the target memory node, and update the memory policy of the target address range to the memory policy indicated by the target policy mode.

7. A memory policy management device, characterized in that, The kernel is used in a multi-memory node system, and the device includes: The first receiving module is used to receive a policy setting request sent by the first process through a preset system call. The policy setting request includes policy setting parameters and the identifier of the second process. The verification module is used to verify the permissions of the first process, the policy setting parameters, and the second process; The processing module is configured to, if it is verified that the first process has the permission to modify the memory policy, the policy setting parameters are valid, and the second process exists, process the memory policy of the second process according to the policy setting parameters.

8. The apparatus according to claim 7, characterized in that, The device further includes: The second receiving module is used to receive a query request sent by the first process through a virtual file system interface, wherein the query request includes the identifier of the second process; The acquisition module is used to acquire the memory allocation status information of the second process; The return module is used to return the status information to the first process through the virtual file system interface; The first receiving module is specifically used to receive a policy setting request sent by the first process by calling the preset system call through the virtual file system interface.

9. The apparatus according to claim 7 or 8, characterized in that, The preset system call is a memory policy setting function, and the policy setting parameters include the target policy mode, the target node mask pointer, and the maximum number of bits in the node mask. The processing module is specifically used to determine the target memory node pointed to by the target node mask pointer based on the maximum number of bits in the node mask; bind the second process to the target memory node; and update the memory policy of the second process to the memory policy indicated by the target policy mode.

10. The apparatus according to claim 7 or 8, characterized in that, The preset system call is a memory policy acquisition function, and the policy setting parameters include the maximum number of bits in the node mask, the target virtual address, and the query flag. The processing module is specifically used to query the target memory node and target memory strategy corresponding to the target virtual address based on the query flag and the maximum number of bits in the node mask. The target node mask pointer and the target memory policy are returned to the first process, wherein the target node mask pointer points to the queried target memory node.

11. The apparatus according to claim 7 or 8, characterized in that, The preset system call is the home node setting function, and the policy setting parameters include the starting virtual address, the target address range length, and the home node identifier; The processing module is specifically used to determine the target address range corresponding to the second process based on the starting virtual address and the target address range length, wherein the starting address of the target address range is the starting virtual address and the length of the target address range is the target address range length; bind the virtual memory region in the target address range to the memory node corresponding to the home node identifier; and update the memory policy of the target address range to the home node policy.

12. The apparatus according to claim 7 or 8, characterized in that, The preset system call is a memory region binding function, and the policy setting parameters include the starting virtual address, the target address range length, the target policy mode, the target node mask pointer, the maximum number of bits in the node mask, and the configuration flag bits; The processing module is specifically configured to: determine the target address range corresponding to the second process based on the starting virtual address and the target address range length, wherein the starting address of the target address range is the starting virtual address and the length of the target address range is the target address range length; determine the target memory node pointed to by the target node mask pointer based on the configuration flag bit and the maximum number of bits of the node mask; bind the virtual memory region in the target address range to the target memory node; and update the memory policy of the target address range to the memory policy indicated by the target policy mode.

13. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 1-6.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images