An application-insensitive memory management method and memory management system

Abstract

This application discloses an application-insensitive memory management method and memory management system. In this application, the kernel mode only needs to collect memory events once for each physical page. After the physical page is found, other memory events of the same physical page are determined by cross-process matching in the user mode. Finally, the kernel mode performs memory management based on the memory management strategy provided by the user mode. This can avoid the kernel indiscriminately reclaiming high-priority business memory while avoiding program execution exceeding the limit and termination. The entire process does not require modification of business code, thus achieving application-insensitive memory QoS guarantee.

Description

Technical Field

[0001] This application relates to the field of operating system kernel memory management technology, and in particular to an application-insensitive memory management method and memory management system. Background Technology

[0002] In Linux cloud-native hybrid deployment scenarios, the kernel's global memory reclamation mechanism can indiscriminately reclaim hot memory from high-priority services, causing performance fluctuations and request timeouts. Existing eBPF-based memory management solutions require a full traversal of the process's VMA (Virtual Memory Area) in kernel mode to identify hot memory, which can easily trigger the kernel's eBPF instruction limit, leading to forced program termination and complete failure of hot memory identification. For scenarios with multiple processes sharing physical memory, existing solutions can only achieve independent management of a single process and cannot achieve cross-process collaborative processing. Low-priority processes occupying shared memory will continuously increase system memory pressure. Traditional management solutions such as mlock and madvise require intrusive modifications to business code and cannot adapt to the seamless batch deployment requirements of cloud-native services. Summary of the Invention

[0003] To address the need for high-priority business memory performance assurance in cloud-native hybrid deployment scenarios, this paper explores how to avoid the execution boundary limitations of kernel-mode eBPF and prevent hotspot memory identification failures, while simultaneously achieving cross-process collaborative management of shared physical memory among multiple processes, all without the business applications being aware of the process or requiring any modification to the business code.

[0004] This application provides an application-insensitive memory management method, including: The kernel mode captures single-address memory events of high-priority processes through eBPF, extracts the virtual address and physical page frame number corresponding to the event and transmits them to user mode. A single-address memory event is a memory page fault or page reclamation event that is only associated with a single virtual address of a single process. The physical page frame number is a globally unique identifier of a physical page. User space performs cross-process matching based on the physical page frame number to determine all processes sharing the same physical page and the corresponding virtual address range for each process. User space calls the kernel based on process priority to perform memory locking on the virtual address range of high-priority processes and memory reclamation on the virtual address range of low-priority processes.

[0005] Optionally, the kernel mode captures single-address memory events of high-priority processes via eBPF, extracts the corresponding virtual address and physical page frame number, and transmits them to user mode, including: Capture single-address memory events of high-priority processes based on kernel native tracepoints; The virtual address is extracted based on the captured single-address memory event, and the physical page frame number corresponding to the virtual address is obtained by performing page table traversal through the process memory descriptor. Event data containing virtual address and physical page frame number is encapsulated into a standardized single-address memory event and transmitted to user space through the CPU's circular buffer.

[0006] Optionally, the virtual address is extracted based on the captured single-address memory event, and the physical page frame number corresponding to the virtual address is obtained by performing page table traversal through the process memory descriptor, including: Extract the virtual address from a single memory event to obtain the memory descriptor corresponding to the high-priority process; Based on the memory descriptor and virtual address, a step-by-step offset lookup of the five-level page table is performed to extract the physical page frame number corresponding to the virtual address from the valid page table entries.

[0007] Optionally, event data containing virtual address and physical page frame number can be encapsulated into a standardized single-address memory event and transmitted to user space via the CPU's circular buffer, including: The virtual address, physical page frame number, and process identifier in the event data are encapsulated into a standardized single-address memory event; Standardized single-address memory events are written to a circular buffer configured independently for each CPU; Standardized single-address memory events in the circular buffer are pushed to user space according to the lock-free commit rule.

[0008] Optionally, user space performs cross-process matching based on the physical page frame number to determine all processes sharing the same physical page and the corresponding virtual address range for each process, including: The virtual memory region information of the target process is read based on the physical page frame number, and the virtual memory region to which the virtual address corresponding to the event belongs is matched. The global reference count of a physical page can be queried using the physical page frame number to determine the multi-process sharing status of the physical page. A global inverse index based on the physical page frame number is used to match all processes sharing the same physical page and the corresponding virtual address range for each process.

[0009] Optionally, a global inverted index based on the physical page frame number is used to match all processes sharing the same physical page and the corresponding virtual address range for each process, including: Listen for virtual memory region change events of the process via network sockets; Based on virtual memory region change events, incrementally update the global inverse index corresponding to the physical page frame number and the process virtual address; By using the updated global inverted index, we can retrieve all processes sharing the same physical page and their corresponding virtual address ranges.

[0010] Optionally, user space may invoke the kernel to perform memory locking on the virtual address range of high-priority processes and memory reclamation on the virtual address range of low-priority processes, including: The priority of processes sharing the same physical page is determined based on the control group configuration; Based on the priority of each process, a management strategy including memory locking instructions and memory reclamation instructions is generated; The memory locking and memory reclamation operations in the management strategy are executed through cross-process memory management system calls.

[0011] Optionally, memory locking and memory reclamation operations in the management strategy can be executed via cross-process memory management system calls, including: Based on the process identifier in the management policy, open the process file descriptor of the target process; Based on management strategies, on-demand memory locking is performed on the virtual address range of high-priority processes; Based on the management policy, the specified memory range of the virtual address range of the low-priority process is released, thus completing the execution of the management policy.

[0012] Optionally, user space writes the management policy into the BPF hash map, and kernel-mode eBPF reads the management policy from the BPF hash map and performs memory locking or memory reclamation operations on the corresponding virtual address range in kernel space.

[0013] This application also provides an application-insensitive memory management system, comprising: The kernel-mode acquisition unit is used to capture single-address memory events of high-priority processes via eBPF, extract the virtual address and physical page frame number corresponding to the event and transmit them to user space. A single-address memory event is a memory page fault or page reclamation event that is only associated with a single virtual address of a single process. The physical page frame number is a globally unique identifier of a physical page. User-mode clustering units are used to perform cross-process matching based on physical page frame numbers to determine all processes sharing the same physical page and the virtual address range corresponding to each process. The user-mode management unit is used to perform memory locking on the virtual address range of high-priority processes and memory reclamation on the virtual address range of low-priority processes based on process priority.

[0014] The beneficial effects of this application are as follows: This application addresses existing problems by proposing an application-insensitive memory management method and system. First, kernel-mode eBPF single-address memory event collection processes only single-process, single-address memory events, extracting the virtual address and corresponding physical page frame number. Then, user-mode performs cross-process matching based on the physical page frame number to fully obtain all processes sharing the same physical page and their corresponding virtual address ranges. Finally, user-mode, based on process priority, calls the kernel to perform memory locking on the virtual address range of high-priority processes and memory reclamation on the corresponding range of low-priority processes. At this point, the kernel only needs to collect memory events once per physical page. After finding the physical page, other memory events for the same physical page are determined by user-mode cross-process matching. Finally, the kernel manages memory based on the memory management strategy provided by user-mode. This prevents the kernel from indiscriminately reclaiming high-priority service memory while avoiding program execution exceeding limits and termination. The entire process requires no modification to the business code, achieving application-insensitive memory QoS (Quality of Service) assurance. Attached Figure Description

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

[0016] Figure 1 A flowchart illustrating a memory management method according to an embodiment of this application is shown; Figure 2 This diagram illustrates a structural block diagram of a memory management system according to an embodiment of this application. Detailed Implementation

[0017] To more clearly illustrate this application, the following description, in conjunction with preferred embodiments and accompanying drawings, further clarifies the application. Similar components in the drawings are indicated by the same reference numerals. Those skilled in the art should understand that the specific description below is illustrative rather than restrictive and should not be construed as limiting the scope of protection of this application.

[0018] Taking memory management in cloud-native hybrid deployment scenarios as an example, existing technologies employ a memory hotspot identification and locking scheme based on eBPF. This scheme hooks memory page fault events in the kernel-level eBPF program, traverses the entire virtual memory region list of the target process, matches the virtual memory region to which the page fault address belongs, counts the number of page faults in each virtual memory region to identify hot memory intervals, and then performs locking operations on the hot memory intervals through the kernel-level eBPF program. When the number of virtual memory regions in the target process exceeds 2000, the number of instructions required by the kernel-level eBPF program to traverse the virtual memory region list exceeds the kernel's set limit for the number of eBPF instructions, causing the eBPF program to be forcibly terminated by the kernel, and the hot memory identification function fails. At the same time, this scheme can only perform memory management on a single process that triggers a page fault event, and cannot perform collaborative processing on multiple processes sharing the same physical memory. Low-priority processes occupying shared physical memory will continuously increase the system memory pressure, and this scheme requires business processes to modify their code to adapt to the memory locking logic, which cannot meet the deployment requirements of existing businesses.

[0019] Based on this, such as Figure 1 As shown, this application provides an application-insensitive memory management method including: S1: The kernel mode captures single-address memory events of high-priority processes through eBPF, extracts the virtual address and physical page frame number corresponding to the event and transmits them to user mode. A single-address memory event is a memory page fault or page reclamation event that is only associated with a single virtual address of a single process. The physical page frame number is a globally unique identifier of a physical page. S2: User space performs cross-process matching based on the physical page frame number to determine all processes sharing the same physical page and the corresponding virtual address range for each process; S3: User mode calls the kernel to perform memory locking on the virtual address range of high-priority processes and memory reclamation on the virtual address range of low-priority processes based on process priority.

[0020] In practical use, this solution first collects single-address memory events in kernel-mode eBPF, processing only single-process, single-address memory events to extract the virtual address and corresponding physical page frame number. Then, user-mode performs cross-process matching based on the physical page frame number to obtain all processes sharing the same physical page and their corresponding virtual address ranges. Finally, user-mode calls the kernel based on process priority to lock the virtual address range of high-priority processes and reclaim memory for the corresponding range of low-priority processes. At this point, kernel-mode only needs to collect memory events once for each physical page. After finding the physical page, other memory events for the same physical page are determined by user-mode cross-process matching. Finally, kernel-mode performs memory management based on the memory management strategy provided by user-mode. This can prevent the kernel from indiscriminately reclaiming high-priority service memory while avoiding program execution exceeding limits and termination. No business code needs to be modified throughout the process, achieving memory QoS guarantee that is imperceptible to the business.

[0021] Specifically, the kernel-mode process of capturing single-address memory events of high-priority processes via eBPF, extracting the corresponding virtual address and physical page frame number, and transmitting them to user mode involves three sub-processing steps: capturing single-address memory events of high-priority processes based on kernel native tracepoints; extracting the virtual address based on the captured single-address memory events; obtaining the physical page frame number corresponding to the virtual address by performing page table traversal through the process memory descriptor; and encapsulating the event data containing the virtual address and physical page frame number into a standardized single-address memory event, which is then transmitted to user mode via the CPU circular buffer.

[0022] Specifically, this method captures single-address memory events of high-priority processes based on kernel-native tracepoints. The kernel-native tracepoints used are stable trace hooks reserved in the mainline Linux kernel version. Their application binary interfaces are fixed and will not undergo incompatible changes with kernel version updates. This differs from kernel function probe hooks, which depend on the specific implementation and name of the kernel function. The name, parameters, and implementation logic of kernel functions may change in different kernel versions, causing the hook to fail. Kernel-native tracepoints, on the other hand, are maintained by the official kernel team, maintaining compatibility in major kernel iterations. They are compatible with all mainline Linux kernel versions, as well as various distributions derived from the mainline kernel. The kernel-native tracepoints used in this embodiment include the handle_mm_fault tracepoint, the mm_page_reclaim tracepoint, the mmap tracepoint, and the munmap tracepoint. The `handle_mm_fault` tracepoint is triggered at the entry point where the kernel handles user-mode memory page faults. When the physical page corresponding to the virtual address accessed by a user-mode process is not in memory, the kernel triggers this tracepoint. The trigger parameters of this tracepoint include one and only one virtual address, along with the corresponding process identifier and page fault type. Based on the single virtual address parameter carried by this tracepoint, the corresponding memory event can be identified as a single-address memory event. The `mm_page_reclaim` tracepoint is triggered when the kernel performs physical page reclamation operations. The trigger parameters of this tracepoint include one and only the address information corresponding to the reclaimed physical page, along with the corresponding process identifier and reclamation reason. Based on the single address parameter carried by this tracepoint, the corresponding memory event can be identified as a single-address memory event. The `mmap` and `munmap` tracepoints are triggered when a process performs virtual memory region creation or destruction operations. The trigger parameters include the process identifier, the start and end addresses of the virtual memory region, and the permission flags of the virtual memory region. These are used to capture changes in the process's virtual address space, providing triggering conditions for updates to the user-mode index. In this application, the memory event corresponding to the trace point that carries one and only a single address parameter when triggered is identified as a single address memory event. This type of event is associated with only a single process and a single virtual address, and does not contain virtual address ranges or multiple virtual address information.

[0023] In this embodiment, the kernel-mode eBPF program maintains a list of process identifiers for high-priority processes through a BPF array mapping. The BPF array mapping is a fixed-length array-type storage structure provided by the Linux kernel eBPF module, supporting bidirectional read / write between kernel and user modes. Each element of the array corresponds to a process identifier value. After capturing an event triggered by a tracking point, the eBPF program first checks if the process identifier that triggered the event exists in the BPF array mapping. If it exists, subsequent processing is executed; otherwise, the current processing is terminated. This processing can filter invalid events from non-target processes, reduce kernel-mode processing overhead, prevent irrelevant events from occupying the storage space of the circular buffer, and focus on the memory events of the target business processes, preventing irrelevant events from interfering with the generation of subsequent management strategies. In cloud-native hybrid deployment scenarios, operations personnel can add the process identifiers of online transaction-type business processes to the BPF array mapping. The eBPF program only performs subsequent processing on the memory events of these processes, leaving the memory events of offline data analysis processes unprocessed, thereby achieving targeted management of the target business processes.

[0024] Specifically, the process of extracting the virtual address based on the captured single-address memory event and obtaining the physical page frame number corresponding to the virtual address by performing page table traversal through the process memory descriptor includes three sub-processing steps: extracting the virtual address from the single-address memory event, obtaining the memory descriptor corresponding to the high-priority process, and performing a step-by-step offset lookup of the five-level page table based on the memory descriptor and the virtual address, and extracting the physical page frame number corresponding to the virtual address from the valid page table entries.

[0025] In this embodiment, the virtual address is extracted from a single-address memory event to obtain the memory descriptor corresponding to the high-priority process. The memory descriptor in question is a core structure in the Linux kernel that manages the virtual address space of processes. Each user-mode process in the Linux kernel corresponds to a `task_struct` structure, which is the core carrier for kernel process management, storing all information such as the process's running status, resource usage, and permission configuration. The `task_struct` structure contains a pointer to the process's memory descriptor `mm_struct` structure. The `mm_struct` structure contains all management information about the process's virtual address space, including the virtual memory region linked list, page global directory pointer, and memory statistics. The eBPF program obtains the starting address of the current process's `task_struct` structure using the kernel-provided helper function `bpf_get_current_task`, and then reads the `mm_struct` structure pointer within it using the structure offset to obtain the memory descriptor of the current process. To address the issue of varying structure member offsets across different kernel versions, this application employs BPFCO-RE technology for adaptation. BPFCO-RE is a compile-once, run-everything (COPY) solution that automatically adapts to changes in structure member offsets across different kernel versions during the compilation phase. This eliminates the need to compile eBPF programs separately for different kernel versions, improving cross-version compatibility. For different Linux distributions from kernel 4.15 to 6.5, BPFCO-RE technology automatically adapts the offsets of the `mm` field in the `task_struct` structure and the `pgd` field in the `mm_struct` structure, ensuring that the eBPF program can correctly read memory descriptor information across different kernel versions without requiring code modification or recompilation for each kernel version.

[0026] Specifically, based on memory descriptors and virtual addresses, a step-by-step offset lookup of the five-level page table is performed. The five-level page table used is the virtual address to physical address mapping management mechanism used by the Linux kernel under the x86_64 architecture. The five levels of page tables are the page global directory, the page fourth-level directory, the page parent directory, the page intermediate directory, and the page table. Each page table corresponds to a contiguous physical page. Each page table contains multiple page table entries. Each page table entry is 8 bytes long and stores the starting physical address of the next level page table or the physical address of the final physical page and permission flags. The virtual address is divided into five offset segments and one page offset segment of fixed length. Each offset segment corresponds to the lookup index of the first-level page table. With a 4KB physical page configuration, bits 47 to 39 of the virtual address in the x86_64 architecture are the index offsets of the page global directory, bits 38 to 30 are the index offsets of the fourth-level page directory, bits 29 to 21 are the index offsets of the parent directory, bits 20 to 12 are the index offsets of the middle directory, and bits 11 to 0 are the page offsets. The eBPF program reads the starting address of the page global directory from the memory descriptor and performs a step-by-step lookup of the five-level page table according to the offset segments of the virtual address. The validity of the page table entry is checked at each level. If a page table entry at a certain level is invalid, the current lookup process is terminated. If all five levels of page table lookups are valid, the final page table entry is obtained. This step-by-step query process involves a fixed number of operations without loop traversal logic. The number of instructions generated during execution is fixed and will not increase with changes in the number of virtual memory regions of the process. This allows the number of instructions in this step to be controlled within a fixed range, avoiding exceeding the eBPF instruction limit set by the kernel and ensuring the stable operation of the eBPF program.

[0027] In this embodiment, the physical page frame number corresponding to the virtual address is extracted from the valid page table entry. The physical page frame number is the number of the physical page. Each physical page in the system corresponds to a unique physical page frame number. In the Linux kernel, the physical address is calculated by shifting the physical page frame number left by the page offset bits and adding it to the page offset. The valid page table entry stores the physical page frame number and permission flag bits of the physical page. The eBPF program extracts the physical page frame number field from the valid page table entry, completing the conversion from virtual address to physical page frame number. With a 4KB physical page configuration, the page offset bits are 12 bits, and the physical page frame number is the value obtained by shifting the physical address right by 12 bits. The eBPF program reads the corresponding field from the valid page table entry to obtain the physical page frame number corresponding to the virtual address. The physical page frame number is a globally unique identifier for physical memory and is not restricted by the process virtual address space isolation. When different processes map the same physical page, the corresponding physical page frame numbers are exactly the same, thereby enabling cross-process shared memory matching and providing a foundation for subsequent cross-process collaborative management.

[0028] Specifically, the process of encapsulating event data containing virtual address and physical page frame number into standardized single-address memory events and transmitting them to user space through the CPU circular buffer includes three sub-processing steps: encapsulating the virtual address, physical page frame number, and process identifier in the event data into standardized single-address memory events; writing the standardized single-address memory events into a circular buffer independently configured for each CPU; and pushing the standardized single-address memory events in the circular buffer to user space according to the lock-free commit rule.

[0029] In this embodiment, the virtual address, physical page frame number, and process identifier in the event data are encapsulated into a standardized single-address memory event. The standardized single-address memory event is stored in a fixed-length structure, which includes a process identifier field, a virtual address field, a physical page frame number field, a virtual memory region permission flag field, and an event type field. The process identifier field stores the PID value of the process that triggered the event, which is a 4-byte unsigned integer. The virtual address field stores the virtual address value that triggered the event, which is an 8-byte unsigned integer. The physical page frame number field stores the physical page frame number value corresponding to the virtual address, which is an 8-byte unsigned integer. The virtual memory region permission flag field stores the permission flag value of the virtual memory region to which the virtual address belongs, which is an 8-byte unsigned integer. The event type field stores the type identifier of the event, which is a 1-byte unsigned integer. The type identifier includes a memory page fault event identifier and a page reclamation event identifier, where the value of the memory page fault event identifier is 1 and the value of the page reclamation event identifier is 2. Fixed-length structures ensure consistency in the parsing of event data between kernel mode and user mode, avoiding data parsing errors caused by changes in structure length. At the same time, fixed-length structures simplify the storage space management of the circular buffer and improve the efficiency of writing and reading memory events.

[0030] Specifically, standardized single-address memory events are written to a ring buffer independently configured for each CPU. The CPU ring buffer is a ring buffer mapping provided by the Linux kernel eBPF module, with each CPU core corresponding to an independent ring buffer. eBPF programs running on different CPU cores only operate on the ring buffer corresponding to the current CPU, without the need for locking. This avoids the lock contention overhead in multi-core concurrent scenarios and improves the efficiency of event writing. In an 8-core CPU architecture, eight independent ring buffers can be configured, each with a size of 1MB. eBPF programs running on CPU0 cores only write memory events to the ring buffer corresponding to CPU0, and eBPF programs running on CPU1 cores only write memory events to the ring buffer corresponding to CPU1, thus achieving lock-free concurrent writing. Unlike traditional perfbuffer buffers, circular buffers eliminate the need for double memory copying. Perfbuffer buffers require copying data from kernel space to perfbuffer and then from perfbuffer to user space, resulting in two memory copy operations. Circular buffers, however, directly map the kernel-space buffer space to the user-space address space via memory mapping. User space can directly access the data in the buffer with only one memory copy operation, reducing CPU overhead during data transfer and improving event transmission efficiency. Furthermore, circular buffers support automatic expansion. The buffer size can be adjusted through buffer level monitoring. When the buffer usage exceeds a set threshold, the buffer's storage space is automatically expanded to prevent event packet loss in high-concurrency scenarios.

[0031] In this embodiment, standardized single-address memory events in the ring buffer are pushed to user space according to the lock-free commit rule. The eBPF program reserves storage space of the corresponding length from the ring buffer using the kernel-provided helper function `bpf_ringbuf_reserve`. If the reservation is successful, the standardized single-address memory event is written to the reserved storage space, and then the memory event is submitted using the `bpf_ringbuf_submit` helper function. If the reservation fails, the current processing flow is terminated. The user-space program accesses the storage space of the ring buffer through memory mapping and listens for readable events in the ring buffer using `epoll`. When there is readable event data in the ring buffer, a read operation is automatically triggered to obtain the memory event data. The entire write and read process does not require locking operations, reducing the CPU overhead of data transmission, while ensuring the order of event data and avoiding out-of-order events in multi-core concurrent scenarios.

[0032] Specifically, the user-space process performs cross-process matching based on the physical page frame number to determine all processes sharing the same physical page and the corresponding virtual address ranges of each process. This process includes three sub-processing steps: reading the virtual memory region information of the target process based on the physical page frame number; matching the virtual memory region to which the virtual address corresponding to the event belongs; querying the global reference count of the physical page using the physical page frame number to determine the multi-process sharing status of the physical page; and matching all processes sharing the same physical page and the corresponding virtual address ranges of each process based on the global inverse index of the physical page frame number.

[0033] In this embodiment, the virtual memory region information of the target process is read based on the physical page frame number. The virtual memory region to which the virtual address corresponding to the event belongs is matched. The target process is the high-priority process that triggered the memory event. The user-space program obtains all virtual memory region information of the process by reading the maps file of the corresponding process in the proc file system. The proc file system is a virtual file system provided by the Linux kernel, which can export kernel and process running status information to the user-space program and can be accessed without modifying the kernel. The maps file stores all virtual memory region information of the process. Each virtual memory region includes the start and end addresses of the virtual address range, permission flags, mapped file path, mapping offset, etc. The user-space program matches the virtual address corresponding to the event with the address range of all virtual memory regions to find the virtual memory region containing the virtual address and determine the complete virtual address range to which the virtual address belongs. For example, a user-space program reads the `proc / 1234 / maps` file to obtain all virtual memory region information for process PID 1234. It then traverses the address ranges of all virtual memory regions, finding the virtual memory region starting at 0x7f0000000 and ending at 0x7f0020000. This address range contains the virtual address 0x7f0010000 corresponding to the event, thus determining that the complete virtual address range to which this virtual address belongs is 0x7f0000000 to 0x7f0020000. This step is executed entirely in user space, allowing for arbitrarily complex matching logic, unaffected by the instruction limit of kernel-mode eBPF, and eliminating the need for virtual memory region traversal in kernel mode, thereby fundamentally avoiding the instruction limit exceedance problem of eBPF programs.

[0034] Specifically, the global reference count of a physical page is queried using its physical page frame number to determine the multi-process shared state of the physical page. User-space programs read the `kpagecount` file in the `proc` filesystem to obtain the global reference count of the physical page corresponding to the target physical page frame number. The `kpagecount` file stores the global reference count of each physical page in the system. The global reference count indicates how many processes' page tables map the physical page. If the global reference count is greater than 1, the physical page is determined to be in a multi-process shared state; if the global reference count is equal to 1, the physical page is determined to be in a single-process exclusive state. For example, if a user-space program reads the `proc / kpagecount` file, finds the entry corresponding to physical page frame number 123456, and obtains a global reference count of 4, it can determine that the physical page is mapped by the page tables of 4 processes and is in a multi-process shared state. By determining the global reference count, single-process exclusive physical pages can be filtered out, and cross-process matching is only performed on multi-process shared physical pages, reducing user-space processing overhead and improving management efficiency.

[0035] Specifically, a global inverted index based on the physical page frame number matches all processes sharing the same physical page and their corresponding virtual address ranges. The global inverted index is a hash mapping structure maintained by the user-space program. The key of the hash mapping is the physical page frame number, and the value is a list of process identifiers and their corresponding virtual address ranges sharing the physical page. The user-space program can query the global inverted index using the target physical page frame number as the key to obtain all process identifiers sharing the physical page, as well as the virtual address range mapped to that physical page for each process. Unlike the approach of traversing the pagemap files of all processes in the system every time an event is triggered, the global inverted index allows direct querying of information about shared processes without performing a full traversal each time. This reduces user-space I / O and CPU overhead and improves the response speed of cross-process matching.

[0036] Specifically, the process of matching all processes sharing the same physical page and their corresponding virtual address ranges based on the global inverse index of the physical page frame number includes three sub-processing steps: monitoring the virtual memory region change events of the process through a network socket (netlink); incrementally updating the global inverse index corresponding to the physical page frame number and the process's virtual address based on the virtual memory region change events; and querying all processes sharing the same physical page and their corresponding virtual address ranges using the updated global inverse index.

[0037] In this embodiment, virtual memory region change events of processes are monitored using netlink. Netlink is a communication mechanism provided by the Linux kernel between kernel mode and user mode, supporting event-based asynchronous notifications without requiring user-mode programs to poll the kernel status. User-mode programs subscribe to kernel process event notifications by creating a netlink socket of type NETLINK_CONNECTOR. When a process performs operations such as mmap, munmap, or mprotect, causing a change in the virtual memory region, the kernel pushes an event notification to the user-mode program through the netlink socket. The event notification includes information such as the process identifier, the type of virtual memory region change, and the start and end addresses of the virtual address range. For example, if a user-mode program creates a socket of type NETLINK_CONNECTOR and binds it to the corresponding event group, when process PID 5678 performs an mmap operation to create a new virtual memory region, the kernel will push an event notification to the user-mode program. The notification includes information such as process identifier 5678, change type 'mmap,' start address of the virtual address range 0x7a0000000, and end address 0x7a0020000. Through the event notification mechanism of netlink, user-space programs can be aware of changes in the process's virtual address space in real time, providing triggering conditions for incremental updates of the global inverted index without polling the proc file system, thus reducing system resource overhead.

[0038] Specifically, based on virtual memory region change events, the global inverse index corresponding to the physical page frame number and the process virtual address is incrementally updated. When a user-space program receives a virtual memory region change event, it performs the corresponding index update operation based on the change type. If the change type is mmap, the corresponding process's pagemap file is read, the physical page frame number corresponding to each virtual page within the virtual address range is obtained, and the process identifier and virtual address range are added to the global inverse index entry for the corresponding physical page frame number. The pagemap file is a process page table mapping information file exported from the proc file system; each virtual page corresponds to an 8-byte entry, which stores the physical page frame number and page table flag information for that virtual page. If the change type is munmap, the corresponding process's pagemap file is read, the physical page frame number corresponding to each virtual page within the virtual address range is obtained, and the corresponding process identifier and virtual address range are removed from the global inverse index entry. If the change type is mprotect, the permission flag information for the corresponding virtual address range is updated. For example, if a user-space program receives an mmap event from a process with PID 5678, whose virtual address range is 0x7a0000000 to 0x7a0020000, it reads the `proc / 5678 / pagemap` file and obtains the physical page frame number 123456 corresponding to the virtual page within this range. Then, it adds process ID 5678 and the virtual address range 0x7a0000000 to 0x7a0020000 to the entry in the global inverted index corresponding to physical page frame number 123456. By using incremental updates, the index is only updated when the process's virtual memory region changes, eliminating the need for periodic full scans of all processes in the system. This keeps the CPU overhead of user-space programs at a low level while ensuring consistency between the index and the kernel's actual memory layout.

[0039] In this embodiment of the application, the updated global reverse index is used to query all processes sharing the same physical page and their corresponding virtual address ranges. The user-space program uses the target physical page frame number as the key to query the global reverse index and obtains the entry corresponding to the key. The entry stores the identifiers of all processes sharing the physical page and the virtual address range of each process mapped to the physical page, thus determining all processes sharing the same physical page and the virtual address range corresponding to each process. For example, a user-mode program queries the global inverted index using physical page frame number 123456 as the key and obtains the corresponding entry. The entry contains information about four processes: PID 1234 corresponds to the virtual address range 0x7f0000000 to 0x7f0020000, PID 5678 corresponds to the virtual address range 0x7a0000000 to 0x7a0020000, PID 5679 corresponds to the virtual address range 0x7b0000000 to 0x7b0020000, and PID 5680 corresponds to the virtual address range 0x7c0000000 to 0x7c0020000. This allows us to determine that these four processes are all processes sharing the physical page, and also obtains the virtual address range corresponding to each process.

[0040] Specifically, the user-mode process calls the kernel based on process priority to perform memory locking on the virtual address range of high-priority processes and memory reclamation on the virtual address range of low-priority processes. This process includes three sub-processing steps: determining the priority of each process sharing the same physical page based on cgroup configuration; generating a management policy containing memory locking and memory reclamation instructions based on the priority of each process; and executing the memory locking and memory reclamation operations in the management policy through cross-process memory management system calls.

[0041] In this embodiment, the priority of processes sharing the same physical page is determined based on the control group (cgroup) configuration. cgroup is a process group resource management mechanism provided by the Linux kernel, which can limit and isolate resources such as CPU, memory, and I / O of a process group. In cloud-native scenarios, container processes are configured and isolated using cgroup, and the QoS level of containers in the Kubernetes system is also implemented through cgroup configuration. The user-space program reads the cgroup configuration file of the corresponding process to obtain configuration information such as the process's QoS level, memory resource limits, and reclamation priority. Based on this configuration information, the process priority is determined. Priorities are divided into two levels: high priority and low priority. Online business processes have high priority, while offline task processes have low priority. For example, if the user-space program reads the cgroup configuration of PID1234 and finds that the process's QoS level is Guaranteed, it belongs to an online transaction business process, and its priority is determined to be high priority. If the user-space program reads the cgroup configuration of PID5678, PID5679, and PID5680 and finds that these three processes have a QoS level of BestEffort, they belong to offline data analysis task processes, and their priority is determined to be low priority. By configuring process priorities through cgroups, it is possible to achieve complete alignment with the configuration of cloud-native container orchestration systems, eliminating the need for manual configuration of process priorities and enabling seamless business access. At the same time, it ensures that the priority configuration is consistent with the resource configuration of the container.

[0042] Specifically, based on the priority of each process, a management policy is generated that includes memory locking instructions and memory reclamation instructions. The management policy includes the process identifier of each target process, the target virtual address range, and the type of management action. The management action type for high-priority processes is memory locking, and the management action type for low-priority processes is memory reclamation. For example, for the high-priority process PID 1234, a memory locking instruction is generated with a target virtual address range of 0x7f0000000 to 0x7f0020000. For the low-priority processes PID 5678, PID 5679, and PID 5680, memory reclamation instructions are generated with target virtual address ranges of 0x7a0000000 to 0x7a0020000, 0x7b0000000 to 0x7b0020000, and 0x7c0000000 to 0x7c0020000, respectively. These instructions are then integrated into a complete management policy. The generation of control policies is executed entirely in user space. The policy generation rules can be adjusted according to the actual scenario, without being restricted by kernel space execution. At the same time, the execution scope and intensity of control actions can be dynamically adjusted by combining the system's global memory pressure information.

[0043] Specifically, the process of executing memory locking and memory reclamation operations in the management policy through cross-process memory management system calls includes three sub-processing steps: opening the process file descriptor of the target process based on the process identifier in the management policy; performing on-demand memory locking on the virtual address range of the high-priority process based on the management policy; and performing specified range memory release on the virtual address range of the low-priority process based on the management policy, thus completing the execution of the management policy.

[0044] In this embodiment, based on the process identifier in the management strategy, the process file descriptor of the target process is opened. The user-space program obtains the process file descriptor of the target process through a cross-process memory management system, such as the process file descriptor opening (pidfd_open) system call, by passing in the PID value of the target process. The process file descriptor is a process handle provided by the Linux kernel and can be used for cross-process resource management operations without attaching to the target process or modifying the target process's code. This differs from the traditional ptrace system call, which requires attaching to the target process, causing the target process to pause execution, impacting business performance, and even leading to business anomalies. The pidfd_open system call only obtains the process's file descriptor, without attaching to the target process, and does not affect the target process's operation, ensuring the stability of business operations. pidfd_open is a native system call provided by the Linux kernel, used to create a file descriptor pointing to the target process based on the process identifier. This file descriptor is a process operation handle and can be used as an input parameter for cross-process memory management system calls. This file descriptor has a unique binding relationship with the target process, remains valid throughout the target process's lifecycle, and avoids operational anomalies caused by process identifier reuse. Before performing cross-process memory management operations, the user-mode program calls the `pidfd_open` system call to obtain the target process's process file descriptor, passing the target process identifier and identifier bit parameters. After the kernel verifies the calling process's operation permissions, it returns the corresponding file descriptor. The user-mode program then passes this file descriptor to cross-process memory management system calls such as `process_madvise`. The kernel locates the target process based on the file descriptor and performs memory locking or memory reclamation operations on the target process's virtual address range. After completing the cross-process operation, the user-mode program closes the process file descriptor obtained through `pidfd_open` and releases the corresponding kernel resources. For example, a user-mode program calls the `pidfd_open` system call, passing in PID 1234 to obtain the process file descriptor for that process, and then calls the `pidfd_open` system call sequentially, passing in PIDs 5678, 5679, and 5680 to obtain the corresponding process file descriptors.

[0045] Specifically, based on the management policy, on-demand memory locking is performed on the virtual address range of high-priority processes. The user-space program uses the `process_madvise` system call, passing in the process file descriptor of the high-priority process, the starting address of the target virtual address range, the range length, and the `MADV_WILLNEED` and `MADV_LOCKONFAULT` flags to perform the memory locking operation. The `MADV_WILLNEED` flag prompts the kernel to pre-read the physical pages corresponding to the virtual address range into memory, reducing the number of page faults in subsequent accesses. The `MADV_LOCKONFAULT` flag prompts the kernel to lock the accessed physical pages within the virtual address range into memory, preventing the kernel from reclaiming those physical pages. Unlike the `MADV_LOCKED` flag, the `MADV_LOCKONFAULT` flag does not immediately lock all physical pages in the entire virtual address range; it only locks the physical pages that have actually been accessed. This reduces unnecessary memory locking, lowers the amount of system free memory occupied by locked memory, and avoids system OOM (Out of Memory) errors caused by excessive memory locking. For example, a user-mode program can call the `process_madvise` system call, passing in the process file descriptor (PID 1234), the starting address (0x7f0000000), the interval length (0x20000), and the `MADV_WILLNEED` and `MADV_LOCKONFAULT` flags to perform on-demand memory locking on the virtual address range of the high-priority process. This differs from the traditional `madvise` system call, which can only operate on the virtual address range of the current process and cannot operate on other processes. Traditional `madvise` system calls require modification of the target process's code and internal calling of the `madvise` system call. In contrast, the `process_madvise` system call can execute operations on the virtual address range of other processes through the process file descriptor without modifying the target process's code or restarting it, achieving seamless control over business applications.

[0046] In this embodiment, based on the management policy, a specified range of memory is released from the virtual address range of the low-priority process to complete the management policy execution. The user-mode program uses the `process_madvise` system call, passing in the process file descriptor of the low-priority process, the starting address of the target virtual address range, the range length, and the `MADV_DONTNEED` flag, to perform the memory release operation. The `MADV_DONTNEED` flag is used to prompt the kernel to immediately release the physical pages corresponding to the virtual address range, reducing system memory usage, increasing the system's free memory level, and preventing the kernel from triggering global memory reclamation. For example, the user-mode program sequentially calls the `process_madvise` system call, passing in the process file descriptors of PID5678, PID5679, and PID5680, the corresponding virtual address starting address, the range length, and the `MADV_DONTNEED` flag, respectively, to complete the memory release operation for the virtual address range of the low-priority process. At this point, all instructions in the management policy have been executed.

[0047] Furthermore, user-space programs write management policies to the BPF hash map, while kernel-space eBPF reads these policies and performs memory locking or reclamation operations on the corresponding virtual address ranges in kernel mode. The BPF hash map is a key-value pair storage structure shared by kernel and user modes, supporting bidirectional read / write between the two. User-space programs use the `bpf_map_update_elem` system call to write management policies to the BPF hash map, where the key is the physical page frame number and the value is a management policy structure containing information such as the target process identifier, virtual address range, and management action type. Kernel-space eBPF programs use the `bpf_map_lookup_elem` helper function to read the management policies from the BPF hash map and perform memory locking or reclamation operations on the target process's virtual address range based on these policies. For example, after a user-space program generates a control policy, it writes the control policy structure into the BPF hash map using the physical page frame number 123456 as the key. The kernel-space eBPF program hooks the kernel's `do_madvise` function, reads the control policy from the BPF hash map, and performs corresponding memory locking or memory reclamation operations on the virtual address range of the target process based on the control policy. This implementation reduces the execution latency of control actions, eliminates the need for context switching via user-space system calls, and is suitable for business scenarios with high latency requirements.

[0048] Those skilled in the art will understand that, based on the above-described cross-process memory collaborative management method, embodiments of this application also provide an application-insensitive memory management system, such as... Figure 2As shown, the system includes a kernel-mode acquisition unit, a user-mode clustering unit, a user-mode management unit, and a kernel-mode auxiliary execution unit. The kernel-mode acquisition unit captures single-address memory events of high-priority processes using eBPF, extracts the virtual address and physical page frame number, and transmits them to user mode. The processing flow of the kernel-mode acquisition unit is consistent with the aforementioned kernel-mode event capture, data extraction, and transmission processes, and will not be repeated here. The user-mode clustering unit performs cross-process matching based on the physical page frame number to determine all processes sharing the same physical page and their corresponding virtual address ranges. The processing flow of the user-mode clustering unit is consistent with the aforementioned cross-process matching and global reverse index maintenance processes, and will not be repeated here. The user-mode management unit performs memory locking on the virtual address ranges of high-priority processes and memory reclamation on the virtual address ranges of low-priority processes based on process priority. The processing flow of the user-mode management unit is consistent with the aforementioned priority determination, management policy generation, and cross-process system call execution processes, and will not be repeated here. The kernel-mode auxiliary execution unit is used to read the management policies issued by the user mode and perform memory locking or memory reclamation operations in the corresponding virtual address range. The processing flow of the kernel-mode auxiliary execution unit is the same as that of the BPF hash map read and write and the kernel-mode auxiliary execution process mentioned above, and will not be repeated here.

[0049] For example, the specific application scenario of this application embodiment is a Linux cloud-native hybrid deployment scenario. The underlying operating environment is a Linux 5.15 mainline kernel, a single-node NUMA architecture, and cgroupv2 memory management mechanism is enabled. Two types of business processes are deployed on the node at the same time. The first type is an online transaction Java microservice process, which maps the product index file through the mmap system call and belongs to the K8sGuaranteedQoS level. The second type is three offline data analysis container processes. All three container processes map the same product index file through the mmap system call and belong to the K8sBestEffortQoS level. The four processes share the physical pages corresponding to the same product index file.

[0050] Specifically, the implementation process of this application embodiment in this scenario is as follows.

[0051] First, the initialization and environment configuration steps are executed. A user-space memory management daemon is deployed, and permissions CAP_SYS_PTRACE, CAP_IPC_LOCK, CAP_BPF, and CAP_SYS_ADMIN are configured for it. The eBPF program is loaded, and the kernel's native trace points handle_mm_fault and mm_page_reclaim are hooked. The CPU ring buffer is initialized, with a size of 1MB per CPU. The BPF array mapping is initialized, and the PID of the online transaction Java microservice process is written to the high-priority process list in the BPF array mapping. The user-space daemon starts a netlink socket, listens for virtual memory region change events of the process, initializes the global inverse index corresponding to the physical page frame number and the process's virtual address, and starts three independent worker threads: an event receiving thread, a policy generation thread, and a policy execution thread.

[0052] During business operations, the online transaction Java microservice process handles user order requests and accesses data in the product index file, triggering a user-mode page fault. The kernel calls the `handle_mm_fault` function to handle the page fault, triggering the execution of the eBPF hook function. The eBPF hook function first obtains the PID of the current process, queries the high-priority process list in the BPF array mapping, confirms that the current process PID exists in the high-priority process list, and continues to execute the subsequent processing flow. The eBPF program reserves storage space corresponding to the standardized single-address memory event from the circular buffer corresponding to the current CPU, and fills the process identifier, virtual address, and event type fields in the event structure. The event type is a memory page fault event. The eBPF program obtains the `task_struct` structure of the current process through the `bpf_get_current_task` helper function, reads the pointer to the `mm_struct` structure within it, obtains the memory descriptor of the current process, calls the kernel's native `find_vma` function to match the virtual memory region to which the current virtual address belongs, obtains the permission flag of the virtual memory region, and fills it into the corresponding field of the event structure. The eBPF program reads the starting address of the page global directory from the memory descriptor, performs a step-by-step offset lookup of the five-level page table based on the virtual address, sequentially completing the lookup of the page global directory, the fourth-level page directory, the parent page directory, the intermediate page directory, and the page table. It verifies the validity of each page table entry. After all five levels of page table lookups are valid, it extracts the physical page frame number from the final page table entry and fills it into the corresponding field of the event structure. The eBPF program calls the `bpf_ringbuf_submit` helper function to submit the filled, standardized single-address memory event to the ring buffer. The total number of instructions executed by this eBPF program is 187, which does not exceed the kernel's set limit for the number of eBPF instructions.

[0053] The user-mode daemon's event receiving thread listens for readable events in the circular buffer via epoll. It reads standardized single-address memory events from the circular buffer and extracts the process identifier, virtual address, physical page frame number, and event type fields from the events. The event receiving thread then passes the memory event data to the policy generation thread. The policy generation thread reads the maps file of the corresponding process in the proc filesystem, matches the complete virtual memory region to which the virtual address corresponding to the event belongs, and obtains the virtual address range 0x7f0000000 to 0x7f0020000, corresponding to the mapping range of the product index file. The policy generation thread reads the kpagecount file in the proc filesystem, queries the global reference count corresponding to the target physical page frame number, and finds that the global reference count of the physical page is 4, determining that the physical page is in a multi-process shared state. The strategy generation thread uses the target physical page frame number as the key to query the global inverted index, obtaining all processes sharing that physical page and their corresponding virtual address ranges: 0x7f0000000 to 0x7f0020000 for the online trading process, 0x7a0000000 to 0x7a0020000 for the first offline analysis process, 0x7b0000000 to 0x7b0020000 for the second offline analysis process, and 0x7c0000000 to 0x7c0020000 for the third offline analysis process. The strategy generation thread reads the cgroup configuration files of the four processes, determines the priority of the online trading process as high, and the priority of the three offline analysis processes as low, and generates a management policy. This policy includes memory locking instructions for the high-priority processes and memory reclamation instructions for the three low-priority processes.

[0054] The strategy generation thread passes the control strategy to the strategy execution thread. The strategy execution thread iterates through the process list in the control strategy and executes the control instructions sequentially. First, the strategy execution thread calls the `pidfd_open` system call to obtain the process file descriptor of the high-priority online trading process. Then, it calls the `process_madvise` system call, passing in the process file descriptor, the start address of the virtual address range, the range length, and the `MADV_WILLNEED` and `MADV_LOCKONFAULT` flags to perform on-demand memory locking of the virtual address range of the high-priority process and close the process file descriptor of that process. Next, the strategy execution thread sequentially calls the `pidfd_open` system call to obtain the process file descriptors of three low-priority offline analysis processes. For each process, it calls the `process_madvise` system call, passing in the corresponding process file descriptor, the start address of the virtual address range, the range length, and the `MADV_DONTNEED` flag to perform memory release operations on the virtual address ranges of the three low-priority processes and close the corresponding process file descriptors sequentially. At this point, the entire control strategy has been executed.

[0055] It should be noted that during the operation of the solution, when the offline analysis process starts and executes the mmap system call to map the product index file, the kernel will push virtual memory region change events to the user-space daemon process through the netlink socket. After receiving the event, the user-space daemon process reads the pagemap file of the corresponding process, obtains the physical page frame number corresponding to the virtual address range, and updates the process identifier and virtual address range increment to the global inverted index. There is no need to poll the proc file system, which ensures the real-time performance and accuracy of the global inverted index.

[0056] Those skilled in the art will understand that the order of steps in the embodiments of this application can be adjusted according to the actual scenario, and some steps can be deleted or added according to actual needs. All adjustments do not deviate from the core scope of the technical solution of this application.

[0057] Obviously, the above embodiments of this application are merely examples for clearly illustrating this application, and are not intended to limit the implementation of this application. For those skilled in the art, other variations or modifications can be made based on the above description. It is impossible to exhaustively list all implementation methods here. Any obvious variations or modifications derived from the technical solutions of this application are still within the protection scope of this application.

Claims

1. A memory management method that is application-insensitive, characterized in that, include: The kernel mode captures single-address memory events of high-priority processes through eBPF, extracts the virtual address and physical page frame number corresponding to the event and transmits them to user mode. A single-address memory event is a memory page fault or page reclamation event that is only associated with a single virtual address of a single process. The physical page frame number is a globally unique identifier of a physical page. User space performs cross-process matching based on the physical page frame number to determine all processes sharing the same physical page and the corresponding virtual address range for each process. User space calls the kernel based on process priority to perform memory locking on the virtual address range of high-priority processes and memory reclamation on the virtual address range of low-priority processes.

2. The method according to claim 1, characterized in that, The kernel mode captures single-address memory events of high-priority processes via eBPF, extracts the corresponding virtual address and physical page frame number, and transmits them to user mode, including: Capture single-address memory events of high-priority processes based on kernel native tracepoints; The virtual address is extracted based on the captured single-address memory event, and the physical page frame number corresponding to the virtual address is obtained by performing page table traversal through the process memory descriptor. Event data containing virtual address and physical page frame number is encapsulated into a standardized single-address memory event and transmitted to user space through the CPU's circular buffer.

3. The method according to claim 2, characterized in that, The virtual address is extracted based on the captured single-address memory event. The physical page frame number corresponding to the virtual address is obtained by performing a page table traversal using the process memory descriptor, including: Extract the virtual address from a single memory event to obtain the memory descriptor corresponding to the high-priority process; Based on the memory descriptor and virtual address, a step-by-step offset lookup of the five-level page table is performed to extract the physical page frame number corresponding to the virtual address from the valid page table entries.

4. The method according to claim 2, characterized in that, Event data containing virtual address and physical page frame number is encapsulated into a standardized single-address memory event and transmitted to user space through the CPU's circular buffer, including: The virtual address, physical page frame number, and process identifier in the event data are encapsulated into a standardized single-address memory event; Standardized single-address memory events are written to a circular buffer configured independently for each CPU; Standardized single-address memory events in the circular buffer are pushed to user space according to the lock-free commit rule.

5. The method according to claim 1, characterized in that, User-mode performs cross-process matching based on physical page frame numbers to determine all processes sharing the same physical page and the corresponding virtual address ranges for each process, including: The virtual memory region information of the target process is read based on the physical page frame number, and the virtual memory region to which the virtual address corresponding to the event belongs is matched. The global reference count of a physical page can be queried using the physical page frame number to determine the multi-process sharing status of the physical page. A global inverse index based on the physical page frame number is used to match all processes sharing the same physical page and the corresponding virtual address range for each process.

6. The method according to claim 5, characterized in that, A global inverted index based on the physical page frame number is used to match all processes sharing the same physical page and the corresponding virtual address range for each process, including: Listen for virtual memory region change events of the process via network sockets; Based on virtual memory region change events, incrementally update the global inverse index corresponding to the physical page frame number and the process virtual address; By using the updated global inverted index, we can retrieve all processes sharing the same physical page and their corresponding virtual address ranges.

7. The method according to claim 1, characterized in that, User space calls the kernel based on process priority to perform memory locking on the virtual address range of high-priority processes and memory reclamation on the virtual address range of low-priority processes, including: The priority of processes sharing the same physical page is determined based on the control group configuration; Based on the priority of each process, a management strategy including memory locking instructions and memory reclamation instructions is generated; The memory locking and memory reclamation operations in the management strategy are executed through cross-process memory management system calls.

8. The method according to claim 7, characterized in that, Through cross-process memory management system calls, memory locking and memory reclamation operations in the management strategy are executed, including: Based on the process identifier in the management policy, open the process file descriptor of the target process; Based on management strategies, on-demand memory locking is performed on the virtual address range of high-priority processes; Based on the management policy, the specified memory range of the virtual address range of the low-priority process is released, thus completing the execution of the management policy.

9. The method according to claim 1, characterized in that, User space writes management policies into the BPF hash map, and kernel space eBPF reads the management policies from the BPF hash map and executes memory locking or memory reclamation operations for the corresponding virtual address range in kernel space.

10. An application-insensitive memory management system, characterized in that, include: The kernel-mode acquisition unit is used to capture single-address memory events of high-priority processes via eBPF, extract the virtual address and physical page frame number corresponding to the event and transmit them to user space. A single-address memory event is a memory page fault or page reclamation event that is only associated with a single virtual address of a single process. The physical page frame number is a globally unique identifier of a physical page. User-mode clustering units are used to perform cross-process matching based on physical page frame numbers to determine all processes sharing the same physical page and the virtual address range corresponding to each process. The user-mode management unit is used to perform memory locking on the virtual address range of high-priority processes and memory reclamation on the virtual address range of low-priority processes based on process priority.

Images