Numa system page cache copy management method and system

Abstract

This application provides a method and system for managing page cache replicas in a NUMA system. First, by linking target file page cache identification, NUMA node information acquisition of the accessing entity, and policy-based replica judgment, a read-only replica page is generated in the local memory of the accessing node, avoiding cross-node remote memory access. Then, by combining local replica priority mapping and page fault triggering during process node scheduling changes, dynamic adaptation between process scheduling behavior and page mapping relationships is achieved. Finally, during the read page fault interruption process, page mapping is updated based on the replica strategy, and the association between nodes and access tasks is recorded. This significantly reduces the overhead of remote access to file page caches in multi-NUMA node systems without disrupting the semantics of file page caches, while simultaneously solving the problem of continuous remote access caused by process node drift, significantly improving the overall file access performance and operational stability in concurrent scenarios.

Description

Technical Field

[0001] This application belongs to the field of computer system architecture and memory management technology, and in particular relates to a method and system for managing page cache copies in a NUMA system. Background Technology

[0002] In computer systems supporting NUMA (Non-Uniform Memory Access) architecture, there are significant differences in latency between local and remote memory access across different processor nodes. Existing operating systems typically manage file page caches using a single physical page instance, with each file offset corresponding to only one physical page. When a process across nodes accesses this cached page, it must be done via remote memory access, introducing additional access latency and severely impacting system performance. Current optimizations for NUMA architectures largely focus on page migration schemes. These schemes suffer from high migration overhead, interference with concurrent access, and are unsuitable for multi-node shared file read / write scenarios. Furthermore, when processes are scheduled across NUMA nodes, page mapping cannot dynamically adapt with node changes, easily leading to continuous remote memory access. Therefore, they cannot effectively reduce the remote access overhead of file page caches in multi-NUMA node systems while maintaining the existing file page cache semantics. Summary of the Invention

[0003] This application provides a method for managing page cache replicas in a NUMA system, including the following steps: Identify the target file page cache, obtain the NUMA node information of the access subject accessing the file page cache, determine whether to create a physical replica according to at least one predefined replica generation strategy, and if creation is allowed, allocate a read-only physical page in the memory of the target NUMA node, copy the data of the file page cache to the physical page, and form a replica page; During the access process, the copy page is first mapped to the address space of the accessing subject. The system detects whether the target NUMA node of the process scheduling has changed. When the node changes, the page mapping of the corresponding process is released, causing the process to trigger a page fault. In the memory page fault triggering process, if it is a file type read page fault, the mapping page of the running entity is updated, and the page cache copy of the current node or the nearest node is selected according to the copy strategy. The association relationship between the node and the task list is recorded. The association relationship between the node and the task list refers to the mapping relationship between the NUMA node number and the corresponding access task list.

[0004] This application also provides a NUMA system page cache copy management system, including: The replica page creation module identifies the target file page cache, obtains the NUMA node information of the access subject accessing the file page cache, and determines whether to create a physical replica according to at least one predefined replica generation strategy. If creation is allowed, a read-only physical page is allocated in the memory of the target NUMA node, and the data of the file page cache is copied to the physical page to form a replica page. During the access process, the page fault interrupt module first maps the replica page to the address space of the accessing subject, captures whether the target NUMA node of the process scheduling has changed, and releases the page mapping of the corresponding process when the node changes, causing the process to trigger a page fault interrupt. In the page cache replica selection module, during the memory page fault triggering process, if a file-type read page fault occurs, the module updates the mapping page of the running entity, selects a page cache replica of the current node or a nearby node according to the replica strategy, and records the association between the node and the task list. The association between the node and the task list refers to recording the mapping relationship between the NUMA node number and the corresponding access task list.

[0005] The beneficial effects of this application are as follows: The NUMA system page cache replica management method and system described in this application first generate a read-only replica page in the local memory of the accessing node by linking target file page cache identification, access subject NUMA node information acquisition and policy-based replica judgment, thus avoiding cross-node remote memory access. Then, combined with local replica priority mapping and page fault triggering demapping when process node scheduling changes, dynamic adaptation between process scheduling behavior and page mapping relationship is achieved. Finally, in the read page fault interruption process, the page mapping is updated based on the replica policy, and the association between the node and the access task is recorded. This can significantly reduce the overhead of remote access to file page cache in multi-NUMA node systems without destroying the semantics of file page cache, while solving the problem of continuous remote access caused by process node drift, and significantly improving the overall file access performance and operational stability in concurrent scenarios. Attached Figure Description

[0006] The specific embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0007] Figure 1 A flowchart illustrating a NUMA system page cache copy management method according to an embodiment of this application is shown. Figure 2 This illustration shows a flowchart further comprising a NUMA system page cache copy management method according to an embodiment of the present application; Figure 3 This diagram illustrates a NUMA system page cache copy management system according to an embodiment of this application. Detailed Implementation

[0008] To more clearly illustrate this application, the following description, in conjunction with 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.

[0009] This application provides a method for managing page cache copies in a NUMA system, such as... Figure 1 As shown, it includes the following steps: S1: Identify the target file page cache, obtain the NUMA node information of the access subject accessing the file page cache, determine whether to create a physical replica according to at least one predefined replica generation strategy, and if creation is allowed, allocate a read-only physical page in the memory of the target NUMA node, copy the data of the file page cache to the physical page, and form a replica page; S2: During the access process, the copy page is mapped to the address space of the accessing subject first. The target NUMA node of the process scheduling is captured to see if it changes. When the node changes, the page mapping of the corresponding process is released, causing the process to trigger a page fault. S3: In the memory page fault triggering process, if it is a file type read page fault, update the mapping page of the running entity, select the page cache copy of the current node or the nearest node according to the copy strategy, and record the association relationship between the node and the task list; the association relationship between the node and the task list refers to the mapping relationship between the NUMA node number and the corresponding access task list.

[0010] The NUMA system page cache replica management method described in this application first generates a read-only replica page in the local memory of the accessing node by linking target file page cache identification, access subject NUMA node information acquisition, and policy-based replica judgment during operation, thus avoiding cross-node remote memory access. Then, it combines local replica priority mapping and demapping to trigger page faults when process node scheduling changes to achieve dynamic adaptation between process scheduling behavior and page mapping relationship. Finally, in the read page fault interruption process, the page mapping is updated based on the replica policy, and the association relationship between the node and the access task is recorded. This method can significantly reduce the overhead of remote access to file page cache in multi-NUMA node systems without destroying the semantics of file page cache, while solving the problem of continuous remote access caused by process node drift, and significantly improving the overall file access performance and operational stability of the system in concurrent scenarios.

[0011] In this embodiment, the implementation of the NUMA system page cache replica management method first performs the identification operation of the target file page cache and the acquisition operation of the NUMA node information of the access subject. It should be noted that the target file page cache corresponds to a specific offset position in the file. In the operating system's page caching mechanism, file data is cached in units of fixed-size memory pages, with each memory page corresponding to a fixed-length continuous offset range in the file. The process of identifying the target file page cache specifically involves locating the page cache entry corresponding to the offset using the file's inode information and the file offset corresponding to the access operation. If the file data corresponding to the offset has not yet been loaded into memory, the corresponding data is first read from the storage device into memory to generate the main page. The unique identifier of the target file page cache generated in this step will serve as the retrieval benchmark for all subsequent replica management and consistency control steps.

[0012] In this embodiment, the access subject refers to the task entity that actively initiates file page cache read / write access requests, mainly including various user-mode business processes and kernel-mode worker threads, with file access behavior as the core defining criterion. The access subject focuses on the origin of the file access action, maintaining logical consistency throughout the entire process, including file page cache identification, replica creation condition determination, write operation tracing, and task list binding. It is unaffected by process scheduling switching or runtime node migration, and is used to fix the attribution object of each file access behavior, providing a stable subject association benchmark for the full lifecycle management of replicas.

[0013] In this embodiment, the running entity refers to the task entity currently scheduled and occupied by the processor, actually executing instructions on a specified NUMA node and processor core, with real-time hardware running binding relationship as the core defining basis. The running entity has dynamic and variable characteristics, and will migrate and change nodes and cores according to system load balancing and process scheduling strategies. It is mainly used in real-time scenarios such as file type read page fault interrupt response, page mapping refresh after cross-node scheduling, and local or nearby copy selection matching, to match the current physical running environment of the task and complete dynamic page mapping adaptation.

[0014] For example, when a user-space database process initiates a read operation on a file at offset 0x200000000, the operating system first calculates the page cache index key value corresponding to the offset based on the file's inode number and offset. It then searches the system's page cache hash table using this key value. If a corresponding page cache entry is found, the target file's page cache is identified, and a unique identifier containing the inode number and offset is generated. If no corresponding entry is found, a block device read operation is triggered, reading the 4KB of data corresponding to the offset in the file into the allocated physical page in memory, generating the main page corresponding to that offset, and simultaneously identifying the target file's page cache and generating a corresponding unique identifier.

[0015] Specifically, after identifying the target file page cache, the NUMA node information of the accessing entity is obtained. The accessing entity is either a user-mode process or a kernel-mode thread that initiates the file access operation. The NUMA node information includes the NUMA node number of the processor core currently running on the accessing entity, as well as all NUMA node numbers corresponding to the processor affinity configuration of the accessing entity. Obtaining the NUMA node information of the accessing entity involves reading the currently running processor number recorded in the process's task structure, then using the mapping relationship between processor numbers and NUMA nodes to obtain the NUMA node number currently belonging to the process. Simultaneously, the process's processor affinity mask is read and parsed to obtain all NUMA node numbers that the process is allowed to run on. The NUMA node information obtained in this step will serve as the core input for subsequent replica creation location determination and temporary write domain boundary determination.

[0016] For example, a user-mode database process is currently running on processor core number 36. In the system's default processor-to-NUMA node mapping, every 8 consecutively numbered processor cores correspond to one NUMA node. Processor cores numbered 32 to 39 belong to NUMA node 4. Therefore, by using the currently running processor core number 36, we can obtain that the NUMA node to which this process currently belongs is node 4. At the same time, we can read the processor affinity mask of this process. If the mask allows the process to run on processor cores numbered 32 to 47, then we can resolve that the NUMA nodes that the process is allowed to run on are nodes 4 and 5, thus completing the acquisition of the NUMA node information of the access subject.

[0017] In this embodiment, after obtaining the NUMA node information of the accessing subject, it is determined whether to create a physical copy of the target file page cache on the NUMA node according to at least one predefined copy generation strategy. It should be noted that in this embodiment, the copy generation strategy is a set of specific rules within the copy strategy used to determine whether to allow the creation of a physical copy of the target file page cache, and it only applies to the admission judgment stage before copy creation. The copy generation strategy is used to determine whether to allocate physical pages on the target NUMA node and whether to perform data replication to form a local copy. Its judgment conditions include the strategy configuration corresponding to the accessing process, the file's own attributes, the NUMA node's memory level, the system load status, and the copy access frequency. The predefined copy generation strategy is stored in the operating system's kernel configuration space and can be configured and adjusted by user space through system call interfaces, or initially set through kernel startup parameters. The strategy's judgment logic is executed in the kernel's page fault handling process, ensuring that the copy creation judgment is completed when the process accesses file data. The strategy judgment result generated in this step will directly determine whether to execute the subsequent copy page creation operation.

[0018] Specifically, when the policy determines that replica creation is allowed, a read-only physical page is allocated in the memory of the target NUMA node, and the data from the file page cache is copied to this physical page to form a replica page. It should be noted that the target NUMA node is the NUMA node currently belonging to the accessing subject, or, depending on the policy configuration, any NUMA node allowed to run by the accessing subject. The allocation of physical pages is handled by the operating system's memory management subsystem, prioritizing the acquisition of contiguous physical memory pages from the target NUMA node's local free memory list. The allocated physical page is set to read-only, implemented through permission control bits in the page table entries, ensuring that the process cannot directly write to the replica page. The data copying process for the replica page is completed through the kernel's memory copy function, completely copying the file data from the primary page to the newly allocated read-only physical page. After copying, this physical page becomes the replica page corresponding to the target file page cache.

[0019] In this embodiment, after the replica page is created, it is preferentially mapped to the address space of the accessing subject during subsequent accesses. It should be noted that the address space mapping operation is completed by the operating system's memory management unit. Specifically, in the virtual address space of the accessing subject's process, a page table mapping relationship is established between the virtual address range corresponding to the file page cache and the physical address of the replica page, so that when the process accesses the virtual address, it can directly access the replica page in the local NUMA node. The logic for preferentially mapping replica pages is as follows: when a process initiates access to the target file page cache, the kernel first checks whether a replica page corresponding to the file page cache exists in the NUMA node to which the accessing subject currently belongs. If it exists, a mapping relationship between the process's virtual address and the replica page is established preferentially; if it does not exist, the kernel then searches for a replica page in the nearest NUMA node, or directly maps the main page.

[0020] In this embodiment, during process scheduling, the system detects whether the target NUMA node for process scheduling has changed. It should be noted that the operating system's process scheduler migrates processes between different processor cores based on the system's CPU load. When a process migrates from one processor core corresponding to a NUMA node to another, the target NUMA node for process scheduling changes. This change is detected by setting a detection hook in the kernel's process scheduling return path. Before the process returns from kernel mode to user mode after completing the scheduling switch, detection logic is executed to compare the NUMA node the process is running on after this scheduling with the NUMA node it was running on last time. If they are inconsistent, it is determined that the target NUMA node for process scheduling has changed.

[0021] Specifically, when a change in the target NUMA node for process scheduling is detected, the page mapping corresponding to the process running on the changed NUMA node is released, causing the process to trigger a page fault. It's important to note that releasing the page mapping involves clearing the mapping relationship between the virtual address corresponding to the file page cache and the physical address of the original copy page in the process's page table. Simultaneously, the corresponding page table entry for the process is invalidated, triggering a flush of the processor's translation detection buffer. When the process subsequently accesses the virtual address corresponding to that file page cache again, since a valid mapping relationship no longer exists in the page table, the processor will trigger a page fault, enter the kernel's page fault handling process, and re-establish the page mapping.

[0022] In this embodiment, during the memory page fault triggering process, if it is a file-type read page fault, the mapped pages of the running entity are updated, and a page cache copy of the current node or the nearest node is selected according to the copy strategy. It should be noted that a file-type read page fault refers to a page fault triggered when the process accesses a virtual address mapped to a file, but there is no valid mapping in the page table, and this virtual address corresponds to a file-type memory mapping, not an anonymous memory mapping. The process of updating the mapped pages of the running entity is as follows: In the kernel's page fault handling process, the type of page fault is first determined. If it is a file-type read page fault, then according to the predefined replication strategy, the local memory of the NUMA node to which the current process belongs is first searched to see if a copy page corresponding to the file page cache exists. If it exists, a mapping relationship between the process's virtual address and the local copy page is established, and the mapped page is updated. If no corresponding copy page exists in the local node, then the nearest NUMA node with the lowest access latency to the current node is searched to see if a corresponding copy page exists. If it exists, a mapping relationship between the process's virtual address and the nearest node's copy page is established. If neither the local node nor the nearest node has a usable copy page, then a replica generation strategy is used to determine whether to create a new copy page or directly map the main page.

[0023] In this embodiment, the replica policy is a set of rules for managing the entire lifecycle of page cache replicas. It is used to uniformly constrain the entire process of replica creation conditions, access selection methods, mapping switching logic, consistency maintenance methods, and recycling trigger conditions. The replica policy covers the entire process from replica generation, process access, node scheduling changes, write operation conflict handling to memory pressure-driven recycling, providing a unified execution basis and constraints for the entire page cache replica management mechanism. The parameters of the replica policy can be dynamically adjusted according to system load, node status, business type, and tenant resource quota to adapt to the performance requirements and resource constraints under different operating scenarios. This application does not impose any restrictions on this.

[0024] In this embodiment, after updating the mapped page, the node task list association is recorded. It should be noted that the node task list association refers to recording the mapping relationship between NUMA node numbers and corresponding access task lists. Here, a node is the NUMA node number, and the task list is a linked list of task structures for all processes or threads accessing the corresponding page cache copy on that node. Specifically, the kernel will find the task list corresponding to the NUMA node where the mapped copy page is located, add the task structure of the accessing process to the task list, and update the association storage structure corresponding to the file page cache. This ensures that all tasks accessing the corresponding copy page on that node can be quickly retrieved through the file page cache and NUMA node number. The node task list association generated in this step will serve as the core retrieval basis for subsequent write operation processing and copy reclamation steps.

[0025] In this embodiment, determining whether to create a physical replica based on at least one predefined replica generation strategy can be achieved through a combination of multiple strategy conditions. It should be noted that these multiple strategy conditions can be used individually or in combination, and when used in combination, different priority levels can be set for the different strategy conditions.

[0026] Specifically, determining whether to create a physical copy of the file page cache based on the policy settings of the process accessing it is one implementation of the copy generation strategy. The operating system provides a configuration interface for the copy creation strategy for each process. User space can use this interface to configure whether a copy of the file page cache accessed by a specific process is allowed, as well as parameters such as the priority of copy creation and the range of NUMA nodes allowed for copy creation. When the kernel performs the copy creation determination, it first reads the policy configuration corresponding to the process initiating the access. If the process's policy configuration prohibits copy creation, it directly determines that physical copy creation is not allowed; if the policy configuration allows copy creation, it combines other policy conditions to complete a comprehensive judgment.

[0027] In addition, determining whether to create a physical copy of the corresponding file page cache based on its attributes is another implementation of the copy generation strategy. File attributes include read / write permissions, file type, and extended attributes. The kernel pre-sets corresponding copy creation rules for files with different attributes, and independent copy creation strategies can also be configured for individual files through the file system's extended attribute interface. When performing copy creation judgment, the kernel reads the attributes of the file to which the target file page cache belongs. If the file is read-only or its extended attributes allow copy creation, the policy condition is met; if the file is temporary or its extended attributes prohibit copy creation, physical copy creation is directly disallowed.

[0028] In this embodiment, determining whether to allow the creation of physical replicas and the number of replicas allowed based on the memory level or system load of the target NUMA node is a third implementation of the replica generation strategy. It should be noted that the memory level of a NUMA node refers to multiple thresholds set by the operating system for the memory usage of each NUMA node, including three levels: safety level, warning level, and emergency level. Different levels correspond to different replica creation control rules. System load includes parameters such as system CPU utilization, memory bandwidth utilization, interrupt handling load, and inter-rack interconnect bus utilization, used to comprehensively assess the current operating pressure of the system and adjust the replica creation strategy accordingly.

[0029] Specifically, when the memory usage of the target NUMA node is below the safety watermark, replica creation is allowed, and the number of replicas allowed for a single file is not limited. When the memory usage of the target NUMA node is above the safety watermark but below the warning watermark, replica creation is allowed, but the maximum number of replicas that can be created for a single file on that node is limited. When the memory usage of the target NUMA node is above the warning watermark but below the emergency watermark, new replica creation is suspended, and only the pages of already created replicas are retained. When the memory usage of the target NUMA node is above the emergency watermark, replica creation is not allowed, and the recycling process of already created replicas is triggered. When the overall system CPU load exceeds a preset threshold, or the bandwidth utilization of the inter-rack interconnect bus exceeds a preset limit, new replica creation is suspended to avoid memory copying and page table operations during replica creation exacerbating system load and bus congestion.

[0030] Furthermore, when the access frequency of a page cache replica on a NUMA node falls below a preset threshold, a replica creation suppression window is marked for a preset duration. During this window, no physical replicas of the corresponding file page cache are created. This is the fourth implementation of the replica generation strategy. It should be noted that the access frequency of a page cache replica is calculated by counting the number of times the replica page is accessed per unit time. The kernel maintains an access count for each replica page and updates the replica's access frequency value at fixed statistical intervals. The preset threshold is the minimum number of accesses configured by the system. When the access frequency of a replica falls below this threshold, the replica is determined to be a low-frequency replica, triggering the recycling process and simultaneously marking a replica creation suppression window.

[0031] Specifically, the duration of the replica creation suppression window can be configured through system parameters. Within the suppression window, even if a process accesses the file page cache again and other policy conditions are met, the kernel will not create a new replica for that file page cache on the corresponding node. This avoids the repeated creation and recycling of low-frequency replicas, preventing unnecessary consumption of system resources. When the suppression window ends, the kernel resumes the replica creation judgment process for that file page cache, and re-determines whether to create a replica based on the access situation and policy conditions.

[0032] In this embodiment, after recording the node task list associations, write operation processing and copy reclamation steps can be performed. It should be noted that the write operation processing is executed during the operating system's write-type page fault handling process, and the copy reclamation process includes both synchronous and asynchronous reclamation methods. Asynchronous reclamation is executed through a background reclamation thread in the kernel to avoid blocking the normal operation of user-mode processes. The execution of this step uses the node task list associations generated in the previous steps as the core retrieval basis.

[0033] Specifically, when a write-type page fault occurs, the replica page is marked as obsolete, awaiting asynchronous reclamation by the recycling thread. The access subject corresponding to the write operation is associated only with the main page, and the task chain associated with the write operation is recorded. It's important to note that a write-type page fault occurs when a process initiates a write operation to a virtual address mapped to a file, and there is no valid writable mapping in the page table, triggering a page fault. Since the replica pages are all read-only, processes cannot directly write to them; therefore, all write operations must be associated with the main page of the file page cache to ensure file data consistency.

[0034] In this embodiment, the recycling thread retrieves the node task list associations recorded in the obsolete page record, removes the copy page mapping from the task list, and when the task triggers a page fault again, it associates the task with the main page. It should be noted that the kernel's background recycling thread is an independently running kernel-mode thread, bound to a specified processor core, and iterates through all copy pages marked as obsolete at preset time intervals to perform the recycling operation.

[0035] Specifically, the reclamation thread first reads the task list associations corresponding to the replica pages marked as obsolete. Based on these associations, it retrieves all processes that have mapped the replica page and sequentially unmaps the corresponding replica page entries from their page tables, invalidating them. When these processes subsequently access the virtual address corresponding to the file page cache, a page fault is triggered. During the page fault handling process, the kernel maps the address spaces of these processes to the main page, ensuring that the processes access the latest file data. After unmapping all processes, the reclamation thread releases the physical memory occupied by the replica pages and returns them to the system's free memory list, completing the reclamation of the replica pages.

[0036] In addition, triggering asynchronous page replica reclamation based on preset memory pressure parameters and actual node memory usage is one implementation method for replica reclamation. It should be noted that the memory pressure parameters are system-preset memory level thresholds, corresponding to the memory level thresholds in the replica generation strategy, including two levels: warning level and emergency level. When the memory usage of a NUMA node reaches the corresponding level, asynchronous replica reclamation of the corresponding level is triggered.

[0037] Specifically, when the memory usage of a target NUMA node exceeds the warning threshold, a low-priority asynchronous garbage collection is triggered. The collection thread only collects low-access replica pages with access frequency below a preset threshold, retaining high-access replica pages to balance memory resource consumption and access performance. When the memory usage of a target NUMA node exceeds the emergency threshold, a high-priority asynchronous garbage collection is triggered. The collection thread collects all replica pages on the node in ascending order of access frequency until the node's memory usage falls below the safe threshold, ensuring the availability of system memory resources. When the load on the system inter-rack interconnect bus exceeds a preset threshold, the collection thread suspends unnecessary replica collection operations to avoid page table operations and bus interactions during the collection process exacerbating congestion.

[0038] In this embodiment, the decision to reclaim duplicate pages is based on file attribute settings. When a file is opened without a copy, all multi-copy page caches are reclaimed; when opened in writable mode, copy access permissions are revoked. Asynchronous reclamation of multi-node replicas is another implementation of replica reclamation. It should be noted that the file opening mode is determined by parameters passed to the file opening interface by the process, including read-only, writable, and no-copy modes. The kernel sets corresponding attribute flags for the file based on its opening mode for determining replica reclamation.

[0039] Specifically, when a file is opened without copies, the kernel determines that all copies of that file need to be reclaimed, triggering the highest-priority synchronous reclamation process. This immediately reclaims all multi-copy page caches on all NUMA nodes associated with the file, releases the mapping of these copy pages from all processes, and frees up physical memory. When a file is opened in writable mode, the kernel revokes access permissions to all copy pages, marks all copy pages as obsolete, and performs asynchronous reclamation through a background reclamation thread. This ensures the consistency of file write operations while preventing synchronous reclamation from blocking user-space processes. When a file is opened in read-only mode, no active copy reclamation process is triggered; reclamation is only performed when memory pressure is applied.

[0040] Furthermore, when the access frequency of a page cached copy falls below a preset threshold, asynchronous copy recycling is triggered. The recycling event is recorded, and a copy creation suppression window of a preset duration is marked. This is the third implementation method for copy recycling. It should be noted that this recycling method corresponds to the copy access frequency suppression strategy in the copy generation strategy, forming a closed-loop management of the copy lifecycle.

[0041] Specifically, the kernel's background recycling thread updates the access popularity value of all replica pages at fixed statistical intervals. When it detects that the access popularity of a replica page is lower than a preset threshold, it asynchronously triggers the recycling process for that replica, unmaps the page table of the corresponding process, and releases physical memory. Simultaneously, the kernel records the replica recycling event, caches that file page on the corresponding NUMA node, and creates a suppression window for a preset duration for the replica. Within this window, no new replicas of that file page are created for the cache, avoiding the repeated creation and recycling of low-population replicas and reducing the unnecessary consumption of system resources.

[0042] In file page caching management scenarios within NUMA architecture systems, existing multi-replica optimization solutions suffer from core technical flaws. To ensure file data consistency, current solutions require the entire node to invalidate replicas when a write operation is triggered. In large-scale deployments with hundreds of nodes, this can trigger a full-node TLB (Translation Lookaside Buffer) shootdown storm and bus broadcast congestion, leading to a precipitous drop in system-wide read performance. Furthermore, the replica invalidation cycle covers the entire file opening process, limiting the long-term benefits of replica access. If consistency control is weakened to preserve read performance, data consistency deviations can occur in concurrent read / write scenarios. In addition, existing solutions cannot adapt to scenarios involving dynamic changes in node interconnection topology, multi-process concurrent writes, and high-frequency continuous writes. They also cannot achieve performance isolation between services in multi-tenant shared deployments, failing to balance consistency, read performance, and system overhead.

[0043] Specifically, the process begins with the dynamic partitioning of NUMA interconnect domains and the initialization of directory services, generating interconnect domain partitioning results, local directory proxies for each interconnect domain, and global directory services. It's important to note that a NUMA interconnect domain is a set of nodes consisting of multiple NUMA nodes with access latency below a preset benefit threshold. Nodes within the same interconnect domain exhibit relatively small differences in access latency, while nodes across domains show significant differences. By partitioning interconnect domains, the 128 NUMA nodes in the system can be grouped according to their access latency characteristics, providing a basis for subsequent differentiated consistency management and avoiding the system overhead associated with full-node-scale management operations.

[0044] This application addresses the challenge of balancing the cross-node read performance benefits of multiple replicas with strong consistency control of write operations in large-scale NUMA system file page caching multi-replica management scenarios, while minimizing system overhead and read performance fluctuations caused by write operations. First, it accurately defines node space boundaries through dynamic partitioning of NUMA interconnect domains. Based on this, it creates temporary write domains bound to the lifecycle of a single write operation, shrinking the scope of consistency control from all nodes to the write domain. Simultaneously, nodes outside the domain are marked as read-only, retaining their local replicas. Lightweight consistency verification is achieved solely through inter-domain unicast version notifications, decoupling consistency assurance from read performance benefits. Furthermore, it adapts to concurrent and high-frequency write scenarios through time-series arbitration and write operation merging, adapts to topology changes through dynamic updates of interconnect domains, and achieves business management in multi-tenant scenarios through control group isolation. Throughout the process, the combination of spatial shrinkage of domain partitioning and time compression of lifecycle binding can significantly reduce system interruption and bus overhead of write operations, eliminate read performance fluctuations under large-scale nodes, and achieve performance isolation of multi-tenant services, while strictly complying with POSIX (Portable Operating System Interface) consistency semantics. The preferred embodiments of this application are described in detail below.

[0045] Specifically, in the preferred embodiments of this application, such as Figure 2 As shown, it further includes the following steps: S01: Perform dynamic partitioning and directory service initialization of NUMA interconnection domains, and generate interconnection domain partitioning results, local directory agents and global directory services for each interconnection domain; S02: Based on the aforementioned interconnected domain division results, perform the creation of page cache replicas and metadata association management, generate replica pages with version numbers and interconnected domain ownership information, and synchronize the replica metadata to the corresponding directory proxy and directory service; S03: Capture a write-type page fault, and based on the interconnect domain partitioning result and replica metadata, perform temporary write domain lifecycle initialization, and generate a temporary write domain, corresponding lifecycle ID and timing sequence number bound to the lifecycle of a single write operation; S04: Using the temporary write domain as the boundary, and combining the directory proxy and directory service, perform differentiated consistency control of the read and write domains, and generate the result of the destruction of the copy in the write domain and the version update notification in the read-only domain; S05: Based on the differentiated consistency control results and lifecycle ID, detect the lifecycle status of the write operation, perform automatic degradation of the temporary write domain, and generate the downgraded read-only domain and the rebuilt local copy page; S06: Incorporate parameters for interconnect domain partitioning, temporary write domain control, version verification, and degradation processes into a predefined policy system, and implement policy adaptation and replica reclamation management.

[0046] In this embodiment, the dynamic partitioning of the NUMA interconnect domain and directory service initialization are performed. First, the topology information, inter-node one-way access latency, and interconnect bandwidth data of all NUMA nodes in the system are collected to construct a NUMA interconnect state matrix. It should be noted that the NUMA node topology information, including the processor socket number, rack number, interconnect bus type between nodes, and the correspondence between processors and memory, can be read from the advanced configuration and power interface table provided by the system firmware, or obtained through the interface provided by the kernel's NUMA subsystem. The inter-node one-way access latency is obtained by performing atomic memory operations between the processor cores of two nodes and calculating the round-trip time of the operation. To ensure data accuracy, multiple tests can be performed and the average value taken. The inter-node interconnect bandwidth data is obtained by performing batch memory copy operations between two nodes and calculating the amount of data transferred per unit time.

[0047] It should be noted that the NUMA interconnect state matrix is ​​a 128x128 two-dimensional square matrix. The row index of the matrix represents the source NUMA node number initiating the memory access, and the column index represents the target NUMA node number where the accessed memory is located. Each element in the matrix stores the one-way memory access latency and bidirectional interconnect bandwidth data between the corresponding two nodes, which is a quantitative representation of the interconnect characteristics between nodes. The elements in the diagonal positions of the matrix, that is, the elements with the same row and column numbers, represent the latency and local memory bandwidth of the node accessing its own local memory, which are the baseline values ​​for node access performance. The NUMA interconnect state matrix constructed in this step is the core quantitative basis for subsequent interconnect domain partitioning, replica strategy adaptation, and nearest node selection.

[0048] For example, the system contains 128 NUMA nodes, numbered from 0 to 127. Kernel testing revealed the following: the one-way access latency between the 8 nodes within the same processor socket is 45 nanoseconds, with an interconnect bandwidth of 96 GB / s; the one-way access latency between nodes in different sockets within the same rack is 140 nanoseconds, with an interconnect bandwidth of 32 GB / s; the one-way access latency between nodes across racks is 320 nanoseconds, with an interconnect bandwidth of 8 GB / s; and the latency for each node to access its own local memory is 20 nanoseconds, with a local memory bandwidth of 204 GB / s. Based on this data, the kernel constructs a 128-row, 128-column NUMA interconnect state matrix. In this matrix, the element value corresponding to nodes within the same socket is 45 ns / 96 GB / s; the element value corresponding to nodes in different sockets within the same rack is 140 ns / 32 GB / s; the element value corresponding to nodes in different racks is 320 ns / 8 GB / s; and the diagonal element value is 20 ns / 204 GB / s.

[0049] Those skilled in the art will understand that the role of the NUMA interconnect state matrix in this method is mainly reflected in four aspects. First, this matrix is ​​the sole quantitative basis for interconnect domain partitioning. The kernel uses the inter-node access latency data stored in the matrix, combined with preset benefit thresholds, to complete the clustering of nodes, ensuring that the partitioned interconnect domains conform to the actual interconnect characteristics between nodes. Second, this matrix provides data support for adapting replica creation strategies. The kernel can configure differentiated replica creation rules for different interconnect domains based on the inter-node bandwidth and latency data stored in the matrix. For nodes with high cross-domain access latency, replica creation is prioritized; for nodes with low access latency within the same domain, the number of replicas created can be appropriately limited to balance performance gains and memory resource consumption. Third, this matrix provides a basis for determining the boundaries of temporary write domains. When a write page fault is triggered, the kernel uses the interconnect domains partitioned by the matrix as the initial boundary to create temporary write domains, ensuring that the write domain range fully matches the actual interconnect characteristics between nodes, avoiding unnecessary performance losses due to an excessively large write domain range, or consistency risks due to an excessively small range. Fourth, the matrix provides a quantitative basis for selecting the nearest node replica. When there are no available replica pages on the node where the process is located, the kernel can select the replica page of the nearest node with the lowest access latency based on the inter-node latency data stored in the matrix, thus ensuring the optimal performance of process access.

[0050] In this embodiment, after constructing the NUMA interconnection state matrix, the NUMA interconnection state matrix divides NUMA nodes with inter-node access latency below a preset benefit threshold into the same interconnection domain, generating interconnection domain partitioning results. It should be noted that the preset benefit threshold is a latency threshold configured by the system. This threshold is set based on the premise that the overhead of remotely accessing the main page between nodes within the same interconnection domain is lower than the total overhead of replica creation, invalidation, and conversion detection buffer refresh, ensuring that the overhead of maintaining consistency through accessing the main page within the same interconnection domain is lower than the overhead of maintaining replicas. In a large-scale implementation scenario with 128 nodes, the preset benefit threshold can be set to 60 nanoseconds, or it can be adjusted according to the system's hardware characteristics and business scenarios.

[0051] Specifically, the interconnect domains are partitioned using a density clustering algorithm. Nodes with access latency below a preset benefit threshold are grouped into the same class, with each class corresponding to an interconnect domain. Each interconnect domain is assigned a unique domain number, and the list of NUMA node numbers within each domain, along with the average access latency between nodes within the domain, is recorded to generate a complete interconnect domain partitioning result. For a 128-node scenario, this can ultimately be divided into 16 interconnect domains, each containing 8 nodes within the same slot. Access latency between nodes within the same domain is below the benefit threshold of 60 nanoseconds, while access latency between nodes across domains is above 140 nanoseconds, significantly exceeding the benefit threshold.

[0052] For example, the system presets a benefit threshold of 60 nanoseconds. Based on the aforementioned 128-node NUMA interconnection state matrix, the bidirectional access latency between nodes 0 and 7 is 45 nanoseconds, which is less than 60 nanoseconds. They are clustered into the same category, generating interconnection domain number 0, which contains nodes 0 to 7. The bidirectional access latency between nodes 8 and 15 is 45 nanoseconds, which is less than 60 nanoseconds. They are clustered into the same category, generating interconnection domain number 1, which contains nodes 8 to 15. And so on, ultimately dividing the 128 nodes into 16 interconnection domains. Each interconnection domain contains 8 nodes. The access latency between nodes across interconnection domains is higher than 140 nanoseconds, which is higher than the benefit threshold of 60 nanoseconds, generating a complete interconnection domain division result.

[0053] In this embodiment, after generating the interconnect domain partitioning results, a corresponding local directory agent is started for each interconnect domain, and a global directory service is started. It should be noted that the local directory agent is a kernel-mode thread running on a specified NUMA node within the corresponding interconnect domain, responsible for maintaining the metadata of the page cache replicas within the corresponding interconnect domain. This metadata includes the node number, physical address, version number, and mapped task list of the replica pages. The global directory service is a kernel-mode service running on a specified node of the system, responsible for maintaining the interconnect domain topology information of the entire system, the metadata of the file page cache main page, the global version number baseline, etc., and also responsible for coordinating information synchronization between multiple local directory agents. For the 128-node scenario, a total of 16 local directory agents are started, corresponding to 16 interconnect domains, significantly reducing the overhead of metadata access and avoiding metadata synchronization across all nodes.

[0054] Specifically, each interconnect domain's local directory agent runs on a designated processor core within that interconnect domain. It maintains only the replica metadata within its own interconnect domain. All access to replica metadata within this domain is handled through the local directory agent, eliminating the need for cross-domain access to the global directory service and reducing metadata access latency. The global directory service maintains the interconnect domain partitioning results for the entire system, as well as information such as the physical address, current version number, NUMA node, and interconnect domain of each file page's cached main page. When the main page is updated, the global directory service is responsible for synchronizing the version update information to the corresponding local directory agent.

[0055] For example, for interconnect domain number 0, the kernel starts the corresponding local directory agent on node 0, which runs on a specified processor core of node 0 and is responsible for maintaining the metadata of all page cache replicas of the 8 nodes in interconnect domain 0. For interconnect domain number 1, the kernel starts the corresponding local directory agent on node 8, which runs on a specified processor core of node 8 and is responsible for maintaining the metadata of replicas of the 8 nodes in interconnect domain 1. And so on, starting the corresponding local directory agent for each of the 16 interconnect domains. At the same time, the kernel starts a global directory service on node 0 to maintain the topology information of the 16 interconnect domains of the entire system, the metadata of all file page cache main pages and the global version number base. When the main page is updated, the global directory service synchronizes the version update information to the corresponding local directory agent.

[0056] In this embodiment, based on the generated interconnect domain partitioning result, the creation of page cache replicas and metadata association management are performed. A replica page with version number and interconnect domain affiliation information is generated, and the replica metadata is synchronized to the corresponding directory proxy and directory service. It should be noted that this process is compatible with the aforementioned replica creation process, while adding version number settings and domain association management of metadata to provide data support for subsequent consistency control. The input to this step is the previously generated interconnect domain partitioning result, and the output is the replica page with version number and domain affiliation information, as well as the synchronized replica metadata.

[0057] Specifically, the creation of page cache replicas and metadata association management involves several steps. First, the target file page cache is identified, and the NUMA node information of the access subject is obtained. The implementation method for this step is the same as that for the target file page cache identification and NUMA node information acquisition described above, and will not be repeated here. After obtaining the NUMA node information of the access subject, it is determined whether to create a physical replica of the target file page cache on the NUMA node according to at least one predefined replica generation strategy. The implementation method for this step is the same as that for the replica generation strategy determination process described above, and will not be repeated here. When the strategy determination result is that replica creation is allowed, a read-only physical page is allocated in the memory of the target NUMA node, and the main page data of the file page cache is copied to this physical page to form a replica page. The implementation method for this step is the same as that for the replica page creation process described above, and will not be repeated here.

[0058] In this embodiment, after the replica page is created, a globally monotonically increasing version number is set for both the main page and the replica page. Metadata containing the interconnect domain, version number, and mapping process scheduling affinity information is generated for the replica page, and the metadata is synchronized to the local directory proxy and global directory service of the corresponding interconnect domain. It should be noted that the globally monotonically increasing version number means that the main page and replica page cached for each file page share the same global version number base. The version number of the main page is incremented by 1 after each write operation update. The version number of the replica page is the version number of the corresponding main page at the time of its creation or update. The version number can be used to verify whether the data on the replica page is consistent with that of the main page.

[0059] Specifically, when the main page is first created, its initial version number is set to 1. After each write operation and data synchronization, the version number is incremented by 1, ensuring a globally monotonically increasing version number. When a replica page is created, its version number is set to the latest version number of the current main page, ensuring data consistency between the replica page and the main page. Metadata generated for the replica page includes the interconnect domain number to which the replica page belongs, the current version number of the replica page, scheduling affinity information for all processes mapping the replica page, the NUMA node number where the replica page resides, and its physical address. This generated metadata is first synchronized to the local directory agent of the interconnect domain to which the replica page belongs, where it is maintained. Simultaneously, it is synchronized to the global directory service to update the global replica distribution information.

[0060] For example, when the primary page of the target file page cache is first created, its version number is set to 1. When replica pages are created on nodes 4, 12, and 36, the version number of all replica pages is set to 1. Metadata is generated for the replica page on node 4, where the interconnect domain is 0, the version number is 1, the scheduling affinity information of the mapping process is that it is allowed to run on nodes 4 and 5, the node number is 4, and the physical address is the address of the corresponding physical page. This metadata is synchronized to the local directory agent in interconnect domain 0, and also to the global directory service. Metadata is generated for the replica page on node 12, where the interconnect domain is 1, the version number is 1, the scheduling affinity information of the mapping process is that it is allowed to run on nodes 12 to 15, the node number is 12, and the physical address is the address of the corresponding physical page. The metadata is synchronized to the local directory agent in interconnect domain 1, and also to the global directory service. Generate metadata for the replica page on node 36, where the interconnect domain is 4, the version number is 1, the scheduling affinity information of the mapping process is that it is allowed to run on nodes 32 to 39, the node number is 36, and the physical address is the address of the corresponding physical page; synchronize the metadata to the local directory agent of interconnect domain 4, and also to the global directory service.

[0061] In this embodiment of the application, after the metadata synchronization of the copy page is completed, the copy page is mapped to the address space of the accessing subject. The implementation method of this step is the same as the aforementioned copy page mapping process, and will not be repeated here.

[0062] In this embodiment, a write-type page fault is captured. Based on the interconnect domain partitioning result and replica metadata, a temporary write domain lifecycle initialization is performed, generating a temporary write domain bound to the lifecycle of a single write operation, along with a globally unique lifecycle ID and timing sequence number corresponding to the write operation. It should be noted that a temporary write domain refers to a node management scope bound to the lifecycle of a single write operation and effective only within the write operation execution cycle. By setting a temporary write domain, the scope of consistency management can be limited to the interconnect domain related to the write operation. In a 128-node scenario, only 8 nodes within a single interconnect domain need to be managed, avoiding the management overhead of all 128 nodes. The input to this step is the previously generated interconnect domain partitioning result and replica metadata, and the output is the temporary write domain, a globally unique lifecycle ID, and a timing sequence number.

[0063] Specifically, the process involves capturing write-type page faults and initializing the lifecycle of a temporary write domain. First, a write-type page fault within the system is captured, and a globally unique lifecycle ID and a monotonically increasing sequence number are assigned to this write operation. It's important to note that the lifecycle ID is a unique identifier for this write operation, used to associate it with the corresponding temporary write domain, control rules, and status information. After the write operation is completed, the lifecycle ID is archived, and the corresponding resources are released. The sequence number is a globally monotonically increasing value used to identify the global timing of the write operation. In concurrent write operation scenarios, the sequence number determines the order of write operations, ensuring data consistency.

[0064] For example, after the kernel captures a write-type page fault, it assigns a globally unique lifecycle ID to this write operation with a value of 0x00000100, and at the same time assigns a globally monotonically increasing timing sequence number with a value of 0x00000200. The lifecycle ID and timing sequence number are then associated and stored with the relevant information of this write operation.

[0065] In this embodiment, after allocating the lifecycle ID and timing sequence number, the initiating process information, target file page cache information, offset range, initiating node information, and process scheduling affinity mask for this write operation are recorded. It should be noted that the initiating process information includes the process's task structure pointer, process ID, and control group information; the target file page cache information includes the file's inode number, the file offset range corresponding to the page cache, the physical address of the main page, and the version number; the offset range is the starting address and length of the offset within the file corresponding to this write operation; the initiating node information is the NUMA node number currently running for the write operation initiating process; and the process scheduling affinity mask is the mask corresponding to the processor cores that the process is allowed to run on, which can be parsed to obtain all NUMA node numbers that the process is allowed to run on. This information is used to determine the initial boundary and control scope of the temporary write domain, ensuring that the effective scope of the temporary write domain covers all nodes that may have consistency risks.

[0066] For example, the kernel records the process information for this write operation as the database process with process ID 5678, the target file page cache information as the file with inode number 9012, the offset range as 0x200000000 to 0x200000fff, the main page physical address as 0xffff888000010000, the current version number as 1, the offset range as 4 kilobytes, the initiating node information as NUMA node 4, and the process scheduling affinity mask as allowing operation on processor cores numbered 32 to 47, corresponding to NUMA nodes 4 and 5, both belonging to interconnect domain 0.

[0067] In this embodiment, after recording the relevant information for the write operation, a temporary write domain is created, bounded to the lifecycle ID of the current write operation, using the interconnect domain where the write operation initiating node is located as the initial boundary. The lifecycle status of the temporary write domain is marked as "in execution." It should be noted that the initial boundary of the temporary write domain is the interconnect domain where the write operation initiating node is located. Furthermore, the scope of the temporary write domain can be adjusted based on the process scheduling affinity mask to ensure that the temporary write domain covers all allowed NUMA nodes of the process. The binding of the temporary write domain to the lifecycle ID means that the lifecycle of the temporary write domain is completely consistent with the lifecycle of the current write operation. The temporary write domain is active during the execution of the write operation, and automatically downgrades and ends its lifecycle after the write operation is completed.

[0068] Specifically, the process of creating a temporary write domain includes assigning a unique domain identifier to the temporary write domain, recording information such as the corresponding lifecycle ID, sequence number, list of included NUMA nodes, lifecycle status, and management rules, and synchronizing the temporary write domain information to the global directory service and the local directory agent of the corresponding interconnected domain to ensure that all nodes within the domain can obtain the management information of the temporary write domain. Marking the lifecycle status of the temporary write domain as "in progress" indicates that the write operation is in progress and the management rules for the temporary write domain are in effect.

[0069] For example, the write operation initiating node is NUMA node 4, which belongs to interconnect domain 0 and includes nodes 0 to 7. The allowed running nodes corresponding to the process scheduling affinity mask are nodes 4 and 5, both of which belong to interconnect domain 0. Therefore, the included nodes of the created temporary write domain are nodes 0 to 7 of interconnect domain 0, which are bound to lifecycle ID 0x00000100 and marked as executing. At the same time, the information of the temporary write domain is synchronized to the global directory service and the local directory agent of interconnect domain 0.

[0070] In this embodiment, using the generated temporary write domain as the boundary, and combining directory proxy and directory service, differentiated consistency control is performed on read and write domains, generating replica obsolescence results within the write domain and version update notifications within the read-only domain. It should be noted that this step is the core process of consistency control. By dividing nodes into temporary write domains and read-only domains and executing differentiated processing logic, data consistency is ensured while reducing the impact on read performance. In a 128-node scenario, the temporary write domain only covers 8 nodes in one interconnect domain, while the remaining 120 nodes in 15 interconnect domains are marked as read-only domains, completely unaffected by replica obsolescence operations during write operations. This fundamentally solves the problem of system-wide read performance degradation caused by write operations on large-scale nodes. The input to this step is the previously generated temporary write domain, and the output is the replica obsolescence results within the write domain and the version update notifications within the read-only domain.

[0071] Specifically, based on the boundary of the generated temporary write domain, the interconnect domain outside the temporary write domain is marked as a read-only domain. It should be noted that there is no possibility of scheduling write operation initiation processes for nodes within the read-only domain. Therefore, there is no risk of read-write concurrency consistency, and there is no need to perform replica invalidation operations. Data consistency can be ensured only through version number verification.

[0072] For example, the interconnect domains in the system are 0 to 15, and the temporary write domain is the range of interconnect domain 0. Therefore, all 15 interconnect domains from interconnect domain 1 to 15 are marked as read-only domains, and the read-only domains contain 120 NUMA nodes.

[0073] In this embodiment, during the effective period of the temporary write domain, the replica pages within the temporary write domain are invalidated, using the scope of the temporary write domain as the boundary. This removes the replica page mapping for processes within the temporary write domain, ensuring that the page table of the write operation initiating process is mapped only to the main page. It should be noted that this step ensures that regardless of which node the write operation initiating process is scheduled to within the temporary write domain, it can only access the latest main page, guaranteeing post-write read consistency and preventing processes from reading old replica data.

[0074] Specifically, the kernel performs an obsolescence operation on the replica pages within the temporary write domain. This involves the kernel retrieving all replica pages corresponding to the target file page cache within the temporary write domain via the global directory service and local directory proxy, marking these replica pages as obsolescent, and prohibiting new processes from mapping them. The kernel also removes the page table mappings of replica pages from processes within the temporary write domain. Specifically, based on the task chain associations of the replica pages, it retrieves all processes that have mapped these replica pages, clears the corresponding mappings from their page tables, invalidates the page table entries, and triggers a refresh of the translation detection buffer. Furthermore, the kernel prohibits the creation of new replicas of the target file page cache within the temporary write domain. Specifically, during the execution phase of the temporary write domain, even if a process initiates access to the target file page cache and the replica generation policy conditions are met, the kernel will not create new replica pages within the temporary write domain, ensuring that all processes can only access the main page. Finally, the kernel maps the page table of the process initiating the write operation only to the main page of the target file page cache, and sets the page table entries of the main page to write permissions, ensuring that the process can complete the write operation.

[0075] For example, the scope of the temporary write domain is interconnect domain 0, which includes nodes 0 to 7. The kernel retrieves a copy of the target file page cached on node 4 through the local directory agent of interconnect domain 0, and marks the copy page as obsolete. Based on the node task list association relationship corresponding to the copy page, it retrieves all processes on node 4 that have mapped the copy page, and clears the corresponding mapping relationship in their page tables. During the period when the temporary write domain is in execution, the creation of new copies of the file page on nodes 0 to 7 is prohibited. At the same time, the page table of the process that initiated the write operation is mapped to the main page on node 0, and the page table entries are set to write permissions, so that the process can complete the data writing.

[0076] In this embodiment, after the main page completes the write operation and updates the version number, it sends a unicast version update notification to the local directory agent of the read-only domain through the global directory service, using the marked read-only domain as the addressing target. It should be noted that completing the write operation means the process writes the data to the main page's physical memory, marking dirty pages and ensuring the main page's data is the latest valid data. The main page's version number is incremented by 1 after the data write is completed, ensuring a monotonically increasing version number. The unicast version update notification means the global directory service sends a single version update notification to the local directory agent of each read-only domain. The notification includes the identifier of the target file page cache, the latest version number of the main page, and the update time. It eliminates the need to send notifications to every node or process within the read-only domain. In a 128-node scenario, only 15 unicast notifications are needed instead of 120 full-node broadcasts, significantly reducing cross-node notification overhead and bus congestion.

[0077] Specifically, the global directory service only needs to send M unicast notifications to the local directory agents of M read-only domains, instead of sending N broadcast notifications to N system nodes, where M is the number of read-only domains, which is usually much smaller than the total number of system nodes N. Therefore, it can reduce the notification overhead across nodes and reduce the bandwidth usage of the interconnect bus.

[0078] For example, after the main page completes the write operation and writes the data, the version number is updated from 1 to 2. The global directory service sends a unicast version update notification to each of the 15 local directory agents in the read-only interconnected domains 1 to 15. The notification content includes the inode number of the target file page cache and the latest version number of the main page, 2. There is no need to send notifications to 120 read-only nodes separately. Version information synchronization can be completed with only 15 unicast operations.

[0079] In this embodiment, when a process within a read-only domain accesses a local copy page, it verifies the version number of the copy page against the main page based on the version update notification stored in the local directory proxy. Based on the verification result, it performs the access or update operation for the copy page. It should be noted that when a process within a read-only domain accesses a local copy page, it does not need to access the global directory service across domains; it only needs to access the local directory proxy within the local domain to obtain the latest version number of the main page. The overhead of version verification is low and will not significantly impact the process's access performance.

[0080] Specifically, when a process within a read-only domain initiates an access request to a local copy page, it first queries the local directory proxy of the corresponding interconnected domain for the latest version number of the target file page cached main page, and simultaneously obtains the current version number of the local copy page. The difference between the two version numbers is compared, and the corresponding operation is executed based on the verification result. If the version numbers match, it means the data on the copy page is consistent with the main page, and the process is allowed to directly access the local copy page; if the version numbers do not match, the corresponding access or update operation is executed based on the difference and a preset version barrier window.

[0081] For example, a process within Internet Domain 4 initiates an access request to a local copy page. It queries the local directory agent of Internet Domain 4 and finds that the latest version number of the main page is 2, while the current version number of the local copy page is 1. The difference between the two version numbers is 1, which is within the preset version barrier window. Therefore, the process is allowed to directly access the local copy page. If the subsequent version number difference exceeds the version barrier window, an asynchronous incremental update of the copy page is triggered.

[0082] In this embodiment, based on the differentiated consistency control result and lifecycle ID, the write operation lifecycle status is detected, the temporary write domain is automatically downgraded, and a downgraded read-only domain and a rebuilt local replica page are generated. It should be noted that this step binds the lifecycle of the temporary write domain to the write operation execution cycle. After the write operation is completed, the consistency control restrictions are immediately lifted, replica creation and access are restored, and the time window for replica invalidation is reduced. The input to this step is the previously generated differentiated consistency control result and lifecycle ID, and the output is the downgraded read-only domain and the rebuilt local replica page.

[0083] Specifically, the execution status of write operations is monitored. Once the write operation is complete—data is written to the main page, dirty page marking is performed, version number is updated, and file system metadata is synchronized—the status of the corresponding lifecycle ID is updated to "completed." It's important to note that the completion of a write operation includes not only writing data to the physical memory of the main page but also completing dirty page marking. This ensures the kernel's memory management subsystem can recognize the dirty page status of the page, allowing for subsequent disk write operations. Simultaneously, file system metadata synchronization is completed, ensuring the file's inode information matches the data status. At this point, the entire write operation process is finished, and consistency risks are completely eliminated.

[0084] For example, the kernel detects that the write operation has been completed, the data has been written to the main page, the dirty page mark has been set, the version number has been updated from 1 to 2, and the file system metadata synchronization has been completed. Therefore, the status corresponding to lifecycle ID 0x00000100 is updated from "in progress" to "completed".

[0085] In this embodiment, after updating the lifecycle ID to "completed," a write completion notification is sent to the local directory agent corresponding to the temporary write domain to remove the restriction on replica creation within the temporary write domain. It should be noted that the write completion notification informs the local directory agent that the write operation is complete and the control rules for the temporary write domain can be lifted. Upon receiving the notification, the local directory agent updates the control status of the corresponding file page cache, removes the restriction on replica creation, and allows the creation of a replica page for that file page cache on the node corresponding to the temporary write domain.

[0086] For example, the kernel sends a write completion notification to the local directory agent in interconnect domain 0. Upon receiving the notification, the local directory agent updates the control status of the target file page cache, removes the restriction on replica creation on nodes 0 to 7, and allows the kernel to create a new replica page for that file page cache on nodes 0 to 7.

[0087] In this embodiment, after removing the restriction on replica creation, a local replica page is recreated within the temporary write domain for processes accessing the target file page cache, based on the latest version number of the main page. The metadata of the replica page is updated and synchronized to the local directory proxy. It should be noted that the process of recreating the replica page is consistent with the initial replica creation process, replicating the main page data based on the latest version number to ensure that the data of the newly created replica page is the latest valid data. The version number of the replica page is set to the latest version number of the main page. After creation, the metadata of the replica page is updated, including its interconnect domain, new version number, mapping process information, etc., and synchronized to the local directory proxy and global directory service of the corresponding interconnect domain.

[0088] For example, based on the main page with the latest version number 2, a read-only physical page is allocated in the local memory of node 4, the data of the main page is copied to the physical page, a new replica page is created, and the version number of the replica page is set to 2; the metadata of the replica page is generated and synchronized to the local directory agent and global directory service of interconnect domain 0.

[0089] In this embodiment, after the replica page is recreated, it is mapped to the address space of the corresponding process, the temporary write domain is completely downgraded to a read-only domain, and the corresponding lifecycle ID is archived. It should be noted that after mapping the replica page to the address space of the corresponding process, the process can re-access the replica page of the local node, restoring low-latency local access. The complete downgrading of the temporary write domain to a read-only domain means that all control rules for that temporary write domain are lifted, and the corresponding node resumes normal replica creation and access processes. Archiving the lifecycle ID includes archiving and storing relevant information about this write operation, control records of the temporary write domain, version update information, etc., releasing the corresponding runtime resources, and completing the full lifecycle control of this write operation.

[0090] For example, the newly created replica page on node 4 is mapped to the address space of the corresponding process, allowing the process to directly access the local replica page; the temporary write domain is completely downgraded to a read-only domain, and all control rules are removed; all information corresponding to lifecycle ID 0x00000100 is archived, runtime resources are released, and the entire process control of this write operation is completed.

[0091] In this embodiment, parameters related to interconnect domain partitioning, temporary write domain control, version verification, and degradation processes are incorporated into a predefined policy system to perform policy adaptation and replica reclamation management. It should be noted that this step ensures compatibility between this method and existing policy-based multi-replica management systems. All control parameters can be incorporated into the predefined policy system and dynamically adjusted according to business scenarios and system status, ensuring the adaptability and flexibility of the method. The implementation methods for policy adaptation and replica reclamation management are consistent with those for the aforementioned replica generation and replica reclamation policies, and will not be repeated here.

[0092] In this embodiment, after performing the lifecycle initialization step of the temporary write domain, a concurrent write operation arbitration step can also be performed. It should be noted that in a large-scale scenario with 128 nodes, the probability of multiple nodes and processes simultaneously initiating write operations on the same file page cache increases significantly. The concurrent write operation arbitration step is used to resolve the consistency conflicts and increased system overhead caused by multiple temporary write domains taking effect concurrently. By arbitrating the time sequence number, it ensures that only one temporary write domain is effective at a time, guaranteeing data consistency while reducing system overhead.

[0093] Specifically, using the target file page cache as the search criterion, the system checks whether there are any temporary write fields in the target file page cache that are currently in execution. It should be noted that the kernel can quickly retrieve all temporary write fields corresponding to the target file page cache through the global directory service, and check if there are any temporary write fields with a lifecycle state of "in execution." If so, it indicates that a write operation is currently in progress and arbitration is required.

[0094] For example, the kernel captures a new write-type page fault, assigns it a lifecycle ID of 0x00000101 and a timing sequence number of 0x00000201, and retrieves a temporary write field in the target file page cache with a lifecycle status of "in execution" through the global directory service, with a corresponding lifecycle ID of 0x00000100 and a timing sequence number of 0x00000200.

[0095] In this embodiment, if a temporary write field in an ongoing state is detected, the timing sequence number corresponding to the current write operation is compared with that of the existing temporary write field to generate a timing comparison result. It should be noted that the timing sequence number is a globally monotonically increasing value; a larger sequence number indicates a later initiation time of the write operation, and the corresponding write operation result is the final valid data. Therefore, by comparing the magnitude of the timing sequence numbers, the priority of the write operation can be determined.

[0096] Specifically, if the timing sequence number of this write operation is the latest timing sequence (i.e., the timing sequence number of this write operation is greater than the timing sequence number corresponding to an existing temporary write domain), then the existing temporary write domain is marked as invalid, the control rules corresponding to the existing temporary write domain are removed, and the temporary write domain corresponding to this write operation is set to an active state. It should be noted that after marking an existing temporary write domain as invalid, all its corresponding control rules are removed, including restrictions on replica creation and replica obsolescence, ensuring that the control rules for the new temporary write domain can take effect normally and avoiding rule conflicts between multiple write domains. Simultaneously, the page table of the old write operation initiating process is mapped to the main page corresponding to the new temporary write domain to ensure consistency of write operations.

[0097] For example, if the timing sequence number of this write operation is 0x00000201, which is greater than the timing sequence number of the existing temporary write field (0x00000200), it is the latest timing sequence. Therefore, the kernel marks the existing temporary write field with a lifecycle ID of 0x00000100 as invalid, removes its corresponding control rules, sets the temporary write field with a lifecycle ID of 0x00000101 corresponding to this write operation to a globally effective state, and maps the page table of the old write operation initiating process to the main page to ensure data consistency.

[0098] In this embodiment, if the timing sequence number of the current write operation is not the latest timing sequence (i.e., the timing sequence number of the current write operation is less than the timing sequence number corresponding to an existing temporary write domain), the temporary write domain creation process corresponding to the current write operation is terminated, and the initiation process of the current write operation is associated with the main page corresponding to the currently effective temporary write domain. It should be noted that for write operations with smaller timing sequence numbers, the data written will be overwritten by subsequent update write operations. Therefore, there is no need to create a separate temporary write domain for it; directly associating the initiation process with the currently effective main page can ensure the execution of the write operation while avoiding the system overhead caused by multiple concurrent temporary write domains.

[0099] For example, if the timing sequence number of this write operation is 0x00000199, which is less than the timing sequence number of the existing temporary write domain 0x00000200, it is not the latest timing. Therefore, the kernel terminates the temporary write domain creation process corresponding to this write operation and maps the page table of the process that initiated this write operation to the main page corresponding to the currently effective temporary write domain, so that the process can directly complete the write operation on the main page.

[0100] In this embodiment, after performing the steps of dynamically partitioning the NUMA interconnect domain and initializing the directory service, a step of dynamically updating the interconnect domain can also be performed. It should be noted that in a large-scale system with 128 nodes, the access latency and interconnect bandwidth between nodes will change with variations in system load, bus occupancy, and rack cooling status. Therefore, it is necessary to dynamically update the interconnect domain to ensure that the interconnect domain partitioning results are consistent with the actual hardware interconnect characteristics, thus guaranteeing the effectiveness of differentiated management.

[0101] Specifically, according to a preset time period, access latency and interconnect bandwidth data between all NUMA nodes in the system are re-collected, and the NUMA interconnect status matrix is ​​updated. It should be noted that the preset time period can be configured through system parameters. In large-scale node scenarios, it can be set to 5 seconds, or it can be dynamically adjusted according to changes in system load. When the system load is high, the period can be extended to reduce the impact of data collection operations on system performance; when the system load is low, the period can be shortened to improve the real-time performance of interconnect domain updates.

[0102] For example, the system's preset interconnection status acquisition period is 5 seconds. Every 5 seconds, the kernel re-acquires the one-way access latency and interconnection bandwidth data between each pair of 128 NUMA nodes, and updates the element values ​​in the original 128-row, 128-column NUMA interconnection status matrix.

[0103] In this embodiment, after updating the NUMA interconnection state matrix, the interconnection domain partitioning is re-executed based on the updated NUMA interconnection state matrix to generate an updated interconnection domain partitioning result. The implementation of this step is consistent with the initial interconnection domain partitioning process, employing the same density clustering algorithm and preset benefit threshold to ensure consistency of the partitioning rules.

[0104] For example, based on the updated NUMA interconnect state matrix, the access latency between nodes within the same slot remains 45 nanoseconds, while the access latency between nodes across slots within the same rack becomes 120 nanoseconds, still higher than the preset benefit threshold of 60 nanoseconds. Therefore, the re-partitioned interconnect domain result is consistent with the initial result, still consisting of 16 interconnect domains, each containing 8 nodes within the same slot. If the access latency between nodes in two adjacent slots becomes 55 nanoseconds, lower than the preset benefit threshold of 60 nanoseconds, then the re-partitioned interconnect domain result will change, grouping the 16 nodes corresponding to the two slots into the same interconnect domain.

[0105] In this embodiment, the updated interconnect domain partitioning results are synchronized to the global directory service and all local directory agents, adjusting the interconnect domain information in the replica metadata. It should be noted that the global directory service and local directory agents will adjust their maintained topology information and metadata according to the updated interconnect domain partitioning results to ensure that subsequent management processes are executed based on the latest interconnect domain partitioning results. The interconnect domain information in the replica page metadata will be adjusted according to the new interconnect domain affiliation of the node where the replica page resides to ensure the accuracy of the metadata.

[0106] For example, if the interconnect domain partitioning result is updated and nodes 8 to 15 are adjusted from interconnect domain 1 to interconnect domain 0, the updated partitioning result will be synchronized to the global directory service and all local directory agents. At the same time, the interconnect domain in the metadata of all replica pages on nodes 8 to 15 will be adjusted from 1 to 0.

[0107] In this embodiment, when the interconnect domain partitioning result changes, the boundary of the temporary write domain in the execution state is adjusted synchronously based on the updated partitioning result. It should be noted that if there are temporary write domains in the execution state when the interconnect domain partitioning result changes, the boundary of the temporary write domain needs to be adjusted according to the new interconnect domain partitioning result to ensure that the control scope of the temporary write domain covers all nodes with consistency risks, thus avoiding control loopholes.

[0108] For example, the initial boundary of the temporary write domain is interconnect domain 0, which includes nodes 0 to 7. When the temporary write domain is in the execution state, the interconnect domain partitioning result is updated, and nodes 8 to 15 are assigned to interconnect domain 0. If the scheduling affinity mask of the write operation initiating process allows it to run on nodes 8 to 15, then the kernel will synchronously adjust the boundary of the temporary write domain to the new interconnect domain 0, which includes nodes 0 to 15, and perform corresponding management operations on the replica pages within nodes 8 to 15 to ensure the effectiveness of consistency management.

[0109] In this embodiment, after performing the lifecycle initialization step of the temporary write domain, a write operation merging step can also be performed. It should be noted that in large-scale scenarios with 128 nodes, the scenario where the same file page is frequently written by multiple nodes is more common. The write operation merging step is used to solve the problem of increased system overhead caused by frequent creation and destruction of temporary write domains and repeated invalidation and reconstruction of replicas due to multiple write operations in a short period of time. By merging multiple write operations in a short period of time into a write operation group, the creation and degradation process of the temporary write domain is only executed once, thereby reducing system overhead.

[0110] Specifically, the target file page cache is used as the statistical object to detect the number of write operations triggered within a preset merging window. It should be noted that the preset merging window is a system-configured time window used to count the number of write operations triggered. In large-scale node scenarios, it can be set to 20 milliseconds, or it can be adjusted according to the frequency of write operations in the business. The higher the frequency of write operations, the larger the merging window can be to improve the merging effect.

[0111] For example, the system's preset merging window is 20 milliseconds, and the threshold for the number of write operations is 10. The kernel detects that the target file page is cached within the current 20-millisecond merging window and has already triggered 9 write operations. Including this write operation, the total number reaches 10.

[0112] In this embodiment, if the number of write operations triggered reaches a preset threshold, the write operations within a preset merging window are merged into the same write operation group, and a unified lifecycle ID and temporary write domain are assigned to the write operation group. It should be noted that all write operations within the write operation group share the same lifecycle ID and temporary write domain, eliminating the need to create an independent temporary write domain for each write operation, thus reducing the overhead of creating and destroying temporary write domains. The timing sequence number assigned to the write operation group is the timing sequence number of the last write operation within the merging window, ensuring that the timing of the write operation group is up-to-date.

[0113] For example, if the number of write operations triggered within the merge window reaches a preset threshold of 10, the kernel will merge these 10 write operations into the same write operation group, assign a unified lifecycle ID 0x00000200 and a timing sequence number 0x00000300 to the write operation group, and create a corresponding temporary write domain. The scope of the write domain is the interconnect domain where the node that initiated the write operation is located.

[0114] In this embodiment, the write operation initiation process within the write operation group is included in the unified temporary write domain management scope. The creation and degradation process of the temporary write domain is executed only once within the merge window. It should be noted that within the merge window, the temporary write domain is always in an in-process state. A replica cancellation operation is performed only once at the beginning of the window, and a degradation and reconstruction operation is performed once after the merge window ends, rather than performing cancellation and reconstruction for every write operation. This significantly reduces the number of replica operations and system overhead. Simultaneously, all processes within the write operation group are included in the temporary write domain management scope, and page tables are mapped to the main page, ensuring that all write operations can be executed normally and guaranteeing data consistency.

[0115] For example, the processes that initiate 10 write operations are all included in the unified temporary write domain management scope, and their page tables are all mapped to the main page, so that write operations can be performed normally; within the 20-millisecond merge window, a replica invalidation operation is only performed once at the beginning of the window, and all write operations within the window are performed on the main page, without the need to repeatedly operate on the replica.

[0116] In this embodiment, after the merge window ends, all write operations within the write operation group are completed, and the version number is updated. Based on a unified lifecycle ID, an automatic degradation process for the temporary write domain is executed. It should be noted that after the merge window ends, all write operations have been completed, and the main page's version number is updated to the latest value. At this point, the automatic degradation process for the temporary write domain is executed once to recreate the replica page and restore local replica access. Only one degradation and rebuild operation is performed throughout the entire merge window, significantly reducing system overhead.

[0117] For example, after the 20-millisecond merge window ends, all 10 write operations in the write operation group have completed data writing, the version number of the main page is updated from 1 to 11, the kernel executes the automatic degradation process of the temporary write domain, removes the restriction on replica creation, recreates the replica page based on the latest version number of the main page, maps it to the address space of the corresponding process, and completes the degradation of the temporary write domain.

[0118] In this embodiment, the step of initializing the lifecycle of the temporary write domain can also achieve isolation and control of the read and write domains based on the control group to which the process belongs. It should be noted that in a large-scale system with 128 nodes, a multi-tenant deployment mode is typically adopted. Different tenants' business processes correspond to independent control groups. By configuring independent read and write domain rules for different control groups, replica control and isolation between different tenants can be achieved, preventing write operations by a single tenant from affecting the replica access performance of other tenants, while ensuring the service quality of different tenants' businesses.

[0119] Specifically, the process obtains the control group information of the process initiating the write operation and reads the read / write domain configuration rules and resource quotas of the corresponding control group. It should be noted that the control group is a process group resource management mechanism provided by the operating system, which can limit and isolate access to the processor, memory, and I / O resources of a process group. The operating system kernel presets corresponding read / write domain configuration rules for each control group. These rules can be modified through the user-space control group configuration interface. Configuration content includes parameters such as the scope limit of temporary write domains, memory quotas for replica creation, version barrier window size, replica creation permissions, and the lifecycle limit of temporary write domains. Resource quotas include the total amount of replica memory that processes within the control group can occupy, the maximum number of replica pages that can be created, and the range of processor cores that can be used. After obtaining the task structure information of the process initiating the write operation, the control group information of the process can be obtained through the control group pointer stored in the task structure, and then the read / write domain configuration rules and resource quotas corresponding to that control group can be read.

[0120] For example, in a 128-node NUMA server running the CUOS operating system, four independent tenant services are deployed: tenant A's core transaction service, tenant B's big data analytics service, tenant C's retrieval service, and tenant D's offline archiving service. The system creates corresponding control groups A, B, C, and D for the four tenants' service processes, respectively. The read / write domain configuration rules for control group A include: temporary write domain range limited to interconnect domains 0 to 3, replica creation memory quota of 256GB, version barrier window of 1, and temporary write domain lifecycle limit of 100 microseconds. The read / write domain configuration rules for control group B include: temporary write domain range limited to interconnect domains 4 to 7, replica creation memory quota of 512GB, version barrier window of 3, and temporary write domain lifecycle limit of 500 microseconds. Control groups C and D are also configured with corresponding independent rules. When tenant A's transaction process initiates a write operation that triggers a write-type page fault, the kernel obtains the control group to which the process belongs through the process's task structure. Then, it reads the read / write domain configuration rules and the 256GB replica memory quota corresponding to control group A.

[0121] In this embodiment, the effective scope of the temporary write domain is determined based on the read / write domain configuration rules and the interconnect domain where the write operation initiating node is located. It should be noted that the effective scope of the temporary write domain is first based on the node range defined in the control group's read / write domain configuration rules, and then combined with the processor affinity mask of all processes within the control group to filter out the NUMA nodes that the processes within the control group can actually run on. This ensures that the temporary write domain only covers the nodes that the processes within the control group can run on, and does not extend to nodes where processes from other control groups reside, thus achieving spatial isolation between read / write domains of different control groups.

[0122] For example, taking the above four tenant implementation scenarios, the read / write domain configuration rules of control group A limit the node range to interconnect domains 0 to 3. The processor affinity masks of all processes in control group A allow them to run on nodes in interconnect domains 0 to 3. Therefore, the effective range of the temporary write domain corresponding to tenant A's write operation is interconnect domains 0 to 3. The read / write domain configuration rules of control group B limit the node range to interconnect domains 4 to 7. The processor affinity masks of all processes in control group B allow them to run on nodes in interconnect domains 4 to 7. Therefore, the effective range of the temporary write domain corresponding to tenant B's write operation is interconnect domains 4 to 7. The temporary write domain ranges of the two control groups do not overlap, thus achieving spatial isolation.

[0123] In this embodiment, a temporary write domain is created, bound to the lifecycle ID and control group of the current write operation. The management rules of the temporary write domain only apply to processes within the control group. It should be noted that the created temporary write domain is associated with a corresponding control group identifier, and its corresponding management rules include replica obsolescence operations, replica creation restrictions, and page table mapping rules, which only apply to processes within the control group and have no impact on processes in other control groups. Specifically, replica obsolescence operations within the temporary write domain only remove the page table mapping of the replica page from the process within the control group and do not modify the page tables of processes in other control groups; replica creation restrictions within the temporary write domain only intercept replica creation requests triggered by processes within the control group and do not restrict replica creation by processes in other control groups; page table mapping adjustments by the write operation initiating process only affect the relevant processes within the control group, and processes in other control groups can still access the local replica page normally and are not affected by the management rules of the temporary write domain.

[0124] For example, following the above scenario, when tenant A's transaction process initiates a write operation, the kernel creates a temporary write domain bound to control group A with a lifecycle ID of 0x00000300 for this write operation. The write domain ranges from interconnect domains 0 to 3. The control rules for this temporary write domain only apply to processes within control group A. In practice, the kernel only removes the page table mapping of the target file page replicas for processes within control group A on interconnect domains 0 to 3, prohibits processes within control group A from creating new replicas of that file page on interconnect domains 0 to 3, and maps the page table of the process initiating the write operation within control group A only to the main page. Processes belonging to control groups B, C, and D on interconnect domains 0 to 3 will not have their page table mappings modified and can still access their local replica pages normally. The kernel will not intercept replica creation requests initiated by processes within other control groups, and the business processes of other tenants will not be affected by tenant A's write operation at all.

[0125] Those skilled in the art will understand that the temporary write domains and read-only domains corresponding to different control groups are isolated from each other, and the consistency management process is executed independently based on the read-write domain configuration rules of each control group. It should be noted that each control group can have independent temporary write domain and read-only domain partitioning logic, and the read-write domain partitioning results of different control groups are independent of each other. Even if processes within multiple control groups simultaneously initiate write operations on the same file page cache, consistency management will only be performed within the node scope defined by their respective control groups, and will not affect cross-control groups. The version number management, replica update process, and lifecycle management of temporary write domains of different control groups are all independent of each other, and each executes its corresponding consistency management process. The completion of a write operation and the degradation of a temporary write domain within one control group will not affect the read-write domain status of other control groups. Therefore, in a multi-tenant scenario, performance isolation and service quality assurance are achieved between different tenant services, avoiding performance interference between multi-tenant services.

[0126] For example, continuing the above scenario, tenant A and tenant B's business processes simultaneously initiate write operations on the same file page cache. The kernel creates independent temporary write domains for the two tenants' write operations. Tenant A's temporary write domain ranges from interconnect domain 0 to 3, while tenant B's temporary write domain ranges from interconnect domain 4 to 7. These two temporary write domains are isolated from each other. During tenant A's write operation, replica obsolescence and consistency control are performed only within interconnect domain 0 to 3. Similarly, during tenant B's write operation, replica obsolescence and consistency control are performed only within interconnect domain 4 to 7. The control processes of the two control groups are completely independent and do not interfere with each other. After tenant A's write operation is completed, its corresponding temporary write domain is downgraded to a read-only domain. A replica is recreated only within interconnect domain 0 to 3, without affecting tenant B's temporary write domain status or control processes. The business performance of the two tenants does not interfere with each other, and their respective service quality is guaranteed.

[0127] In this embodiment, the complete implementation of the aforementioned method can be illustrated through the following implementation case of a large-scale 128-node scenario. This example is based on a rack-level multi-socket server configured with 128 NUMA nodes. Each rack has 8 nodes forming a processor socket, for a total of 16 sockets. The one-way access latency between nodes within the same socket is 45 nanoseconds, the one-way access latency between nodes across sockets within the same rack is 140 nanoseconds, and the one-way access latency between nodes across racks is 320 nanoseconds. The server runs the CUOS operating system, whose kernel integrates the aforementioned NUMA system page cache replica management method. The server deploys a distributed cloud database service, with database instances deployed on all 128 nodes. All instances share the same 3TB core business data file. The business load is a mixed read / write scenario of 75% random reads and 25% random writes. This file is configured with extended attributes to allow the creation of multiple replicas. The system's preset replica generation strategy allows the creation of replicas for the file page cache accessed by the database process. The replica reclamation strategy triggers low-hot replica reclamation when node memory utilization exceeds 85%, and triggers full replica reclamation when it exceeds 95%.

[0128] During system startup, the kernel performs a memory atomic operation latency test, collecting one-way access latency and interconnect bandwidth data between each pair of 128 NUMA nodes to construct a 128-row, 128-column NUMA interconnect state matrix. Based on this matrix, with a preset benefit threshold of 60 nanoseconds, a density clustering algorithm is used to perform interconnect domain partitioning, dividing the 8 nodes in each slot into an independent interconnect domain, ultimately generating 16 interconnect domains, numbered 0 to 15. Each interconnect domain contains 8 nodes, with access latency between nodes within the same domain all below 60 nanoseconds, and access latency between nodes across domains all above 140 nanoseconds. A corresponding local directory agent is started for each interconnect domain, bound to the first node of each interconnect domain, responsible for maintaining the replica metadata within the corresponding domain; simultaneously, a global directory service is started on node 0 to maintain the interconnect domain topology information of the entire system, the metadata of all file page cached main pages, and the global version number baseline.

[0129] After the database service starts, database instances on all 128 nodes initiate access to core business data files. Each process on a node triggers a page fault when accessing a corresponding file page. The kernel identifies the target file page cache, obtains the NUMA node information of each accessing process, reads the predefined replica generation policy, determines that replica creation is allowed, allocates read-only physical pages in the local memory of each of the 128 nodes, copies the main page data to generate local replica pages, sets the initial version number of the main page to 1, and sets the version number of all replica pages to 1. Metadata is generated for each replica page, recording its interconnect domain, version number, and mapping process information, and synchronized to the local directory proxy and global directory service of the corresponding interconnect domain. The replica pages on each node are mapped to the virtual address space of the corresponding database process. All processes can then directly access the replica page in local memory when accessing the file page subsequently, without needing to access the main page across nodes, with access latency consistently below 80 nanoseconds.

[0130] During operation, the database process on node 4 was migrated from the processor core of node 4 to the processor core of node 12 by the process scheduler due to system CPU load balancing. The kernel, in the process scheduling return path, detected the change in the target NUMA node from node 4 to node 12, and immediately unmapped the corresponding replica page on node 4, invalidating the page table entry. When the process accessed the virtual address corresponding to that file page again, the processor triggered a page fault. The kernel determined it to be a file-type read page fault, updated the process's mapped page, and, according to the replica policy, found a cached replica page of that file page in node 12's local memory. Therefore, it established a mapping relationship between the process's virtual address and the local replica page on node 12, and simultaneously updated the node task list association relationship corresponding to that file page cache. The process's task structure was removed from the task list on node 4 and added to the task list on node 12, while synchronously updating the metadata in the local directory agent of interconnect domain 1.

[0131] When the database process on node 4 performs a data update operation on the file page and initiates a write operation, a write-type page fault is triggered. The kernel captures this write-type page fault, obtains the initiating process information, the target file page cache information, and that the initiating node is node 4. The process scheduling affinity mask allows it to run on nodes 0 to 7 of interconnect domain 0. A globally unique lifecycle ID 0x00000100 and a globally monotonically increasing time sequence number 0x00000200 are assigned to this write operation, and the lifecycle status is marked as in progress. A temporary write domain bound to lifecycle ID 0x00000100 is created with interconnect domain 0 as the initial boundary. The write domain ranges from nodes 0 to 7 of interconnect domain 0. The information of the temporary write domain is synchronized to the global directory service and the local directory agent of interconnect domain 0.

[0132] Based on the boundary of the temporary write domain, 15 interconnect domains (1 to 15) outside the temporary write domain are marked as read-only domains. An obsolescence operation is performed on the replica page on node 4 within the temporary write domain, marking its status as obsolescence. According to the node task list association relationship corresponding to this replica page, the page table mappings of all processes on nodes 0 to 7 that mapped this replica page are removed. Simultaneously, during the lifecycle period of the temporary write domain (when it is in execution), the creation of new replicas of this file page on nodes 0 to 7 is prohibited. The page table of the process initiating the write operation is mapped only to the main page on node 0, and the page table entries are set to write permissions, allowing the process to complete data writing. During this process, only the conversion detection buffer refresh interrupt is sent to the nodes within interconnect domain 0, without sending any interrupts to the other 120 nodes, significantly reducing interrupt overhead and bus broadcast traffic.

[0133] After the database process completes the data writing on the main page, the kernel marks the main page as a dirty page, updates the main page's version number from 1 to 2, and simultaneously synchronizes the file system metadata. The global directory service sends a unicast version update notification to each of the 15 local directory agents in the read-only interconnect domains 1 to 15. The notification includes the inode number of the target file page and the latest version number of the main page (2), eliminating the need to send notifications to each of the 120 read-only nodes individually. When a database process within a read-only domain accesses a local replica page, it queries the corresponding interconnect domain's local directory agent. The latest version number of the main page is 2, while the version number of the local replica page is 1, a difference of 1. This difference falls within the system's preset version barrier window of 2, allowing direct access to the local replica page without any change in access latency, unaffected by write operations.

[0134] The kernel detects that the write operation has completed its entire execution and updates the status of lifecycle ID 0x00000100 to "completed". It sends a write completion notification to the local directory agent in interconnect domain 0, removing the restriction on replica creation on nodes 0 to 7. Based on the master page with version number 2, it reallocates a read-only physical page in the local memory of node 4, copies the master page data, creates a new replica page with version number 2, updates the replica metadata, and synchronizes it to the local directory agent and global directory service in interconnect domain 0. The new replica page is remapped to the address space of the corresponding process, the temporary write domain is completely downgraded to a read-only domain, the information corresponding to lifecycle ID 0x00000100 is archived, and runtime resources are released. The replica invalidation time window for the entire write operation is only 32 microseconds during the write operation's execution cycle, and local replica access in interconnect domain 0 is restored within 90 microseconds after the write is completed.

[0135] During continuous system operation, the memory usage of node 127 rose to 88%, exceeding the 85% warning threshold. This triggered a replica reclamation policy. Through the local directory agent in interconnect domain 15, it was found that the access frequency of the cached replica of this page on node 127 was 2 times per second, lower than the preset reclamation threshold of 5 times per second. Therefore, the replica page was marked as obsolete, the page table mapping of this replica page by the process on node 127 was released, and the corresponding physical memory was asynchronously released by the background reclamation thread. Simultaneously, a suppression window was created for the replica of this file page cached on node 127, marked for 100 milliseconds, during which no new replicas were created. When the database process on node 127 subsequently accessed this file page, a page fault was triggered. According to the replica policy, the nearest replica page on node 126 was selected for mapping, avoiding cross-rack access to the main page on node 0 and ensuring access performance.

[0136] In this embodiment, during continuous business operation, multiple nodes' database processes simultaneously initiate write operations on the same target file page, triggering a concurrent write operation arbitration process. It should be noted that in a large-scale deployment scenario with 128 nodes, the probability of multiple nodes concurrently accessing the same hot data page increases significantly. The concurrent write operation arbitration process can effectively avoid consistency conflicts and a surge in system overhead caused by multiple temporary write domains taking effect in parallel, ensuring stable system operation under large-scale nodes.

[0137] For example, the database process on node 4 initiates a write operation and creates a temporary write domain with a lifecycle ID of 0x00000100 and a timing sequence number of 0x00000200. While this temporary write domain is in the execution state, the database processes on nodes 12 and 36 simultaneously initiate write operations on the same target file page, triggering write-type page faults respectively. The kernel assigns a lifecycle ID of 0x00000101 and a timing sequence number of 0x00000201 to the write operation on node 12, and assigns a lifecycle ID of 0x00000102 and a timing sequence number of 0x00000199 to the write operation on node 36. Using the target file page cache as a search condition, the kernel retrieves the temporary write domain that already exists in the execution state for the file page through the global directory service, and then compares the timing sequence numbers corresponding to the three write operations to generate a timing comparison result.

[0138] Specifically, the write operation sequence number 0x00000201 on node 12 is the latest sequence number, which is greater than the existing temporary write domain sequence number 0x00000200. Therefore, the kernel marks the existing temporary write domain with a lifecycle ID of 0x00000100 as invalid, removes the corresponding replica creation restriction and replica invalidation status, sets the temporary write domain corresponding to the write operation on node 12 to a globally effective state, and maps the page table of the process that initiated the original write operation on node 4 to the main page corresponding to the new effective temporary write domain, ensuring that the original write operation can be executed normally and that data consistency is not affected. The write operation sequence number 0x00000199 for node 36 is not the latest sequence number, which is less than the sequence number of the existing temporary write domain. Therefore, the kernel terminates the temporary write domain creation process corresponding to this write operation and directly maps the page table of the process that initiated the write operation on node 36 to the main page corresponding to the currently effective temporary write domain. This allows the process to complete the write operation directly on the main page without creating an independent temporary write domain, thus avoiding the system overhead caused by multiple write domains running in parallel.

[0139] In this embodiment, during system operation, a dynamic update process for the interconnect domain is executed according to a preset cycle to adapt to changes in system hardware status and load. It should be noted that in a 128-node rack server, the interconnect bandwidth and access latency between nodes fluctuate with changes in load distribution, bus occupancy, and heat dissipation within the rack. The dynamic update process for the interconnect domain ensures that the domain partitioning results always match the actual interconnect characteristics of the nodes, guaranteeing the effectiveness of differentiated management.

[0140] For example, the system's preset interconnect status acquisition cycle is 5 seconds. Every 5 seconds, the kernel re-acquires access latency and interconnect bandwidth data between 128 nodes, updating the 128-row, 128-column NUMA interconnect status matrix. During this acquisition process, a significant decrease in the load on the interconnect bus within the rack was detected. The node access latency between interconnect domain 0 and interconnect domain 1 decreased from 140 nanoseconds to 55 nanoseconds, below the preset benefit threshold of 60 nanoseconds. Based on the updated NUMA interconnect status matrix, the kernel re-executes density clustering partitioning, merging interconnect domain 0 and interconnect domain 1 into a new interconnect domain 0, containing nodes 0 to 15, generating the updated interconnect domain partitioning result.

[0141] Specifically, the kernel synchronizes the updated interconnect domain partitioning results to the global directory service and all 16 local directory agents, adjusting the interconnect domain information in the metadata of all replica pages on nodes 8 to 15 from the original interconnect domain 1 to the new interconnect domain 0. At this time, a temporary write domain in the execution state is detected in the target file page, with the original boundary being nodes 0 to 7 of interconnect domain 0. Therefore, based on the updated interconnect domain partitioning results, the kernel synchronously adjusts the boundary of this temporary write domain to nodes 0 to 15 of the new interconnect domain 0. At the same time, it is detected that the scheduling affinity mask of the process initiating the write operation allows it to run on nodes 8 to 15. Therefore, the kernel executes a deprecation operation on the target file page replicas in nodes 8 to 15, removes the page table mapping of the corresponding process, and synchronously extends the control rules of the temporary write domain to the newly assigned nodes to ensure that there are no loopholes in consistency control.

[0142] In this embodiment, frequent and continuous write operations on hot data pages during business operations trigger a write operation merging process. It should be noted that in large-scale distributed database scenarios, hot data pages may be written multiple times within a short period. If each write operation independently creates and destroys a temporary write domain, it leads to repeated invalidation and reconstruction of replicas, resulting in significant unnecessary system overhead. The write operation merging process can effectively reduce system overhead in this scenario and improve system operating efficiency.

[0143] For example, the target hot data page is the database transaction log index page. The system's preset merge window is 20 milliseconds, and the write operation trigger threshold is 10 times. The kernel detects that this data page has been triggered by 9 write operations by processes on different nodes within the current 20-millisecond merge window. Adding the write operation initiated by the process on node 20, the total number of triggers reaches 10, which meets the preset threshold. The kernel merges the 10 write operations within the merge window into the same write operation group, assigns a unified lifecycle ID 0x00000200 and a time sequence number 0x00000300 to this write operation group, and creates a corresponding temporary write domain. The scope of the write domain is the interconnect domain 2 where the write operation initiating node is located, including nodes 16 to 23.

[0144] Specifically, the kernel includes all processes initiating the 10 write operations within the write operation group under a unified temporary write domain management scope, mapping the page tables of all processes to the main page of the target file page to ensure that all write operations can be executed normally. Within the 20-millisecond merge window, a replica invalidation operation is performed only once at the beginning of the window. All write operations within the window are executed directly on the main page, eliminating the need to perform replica invalidation, temporary write domain creation, and destruction operations for each write operation. After the merge window ends, all 10 write operations have completed data writing, and the version number of the main page is updated from 1 to 11. Based on the unified lifecycle ID 0x00000200, the kernel executes the automatic degradation process of the temporary write domain, removing the replica creation restriction. Based on the latest version number of the main page, the local replica page is recreated in interconnect domain 2 and mapped to the address space of the corresponding process, completing the temporary write domain degradation. Only one replica invalidation and one replica reconstruction operation are performed within the entire merge window, reducing system overhead by more than 90% compared to handling 10 write operations independently.

[0145] In this embodiment, under a multi-tenant deployment scenario, the read / write domain isolation management process based on control groups continues to run, ensuring performance isolation and service quality between different tenant services. It should be noted that large-scale servers with 128 nodes are typically used for multi-tenant shared deployments. Different tenants have different requirements for performance and consistency. Isolation management based on control groups can achieve differentiated policy configurations for different tenants while avoiding mutual interference between tenant services.

[0146] For example, four tenants deployed on the server correspond to control groups A, B, C, and D, respectively. The business processes of the four tenants simultaneously initiate write operations on the same target file page. The kernel creates independent temporary write domains for the write operations of the four tenants. The temporary write domain of control group A ranges from interconnect domains 0 to 3, the temporary write domain of control group B ranges from interconnect domains 4 to 7, the temporary write domain of control group C ranges from interconnect domains 8 to 11, and the temporary write domain of control group D ranges from interconnect domains 12 to 15. The ranges of the four temporary write domains do not overlap and are completely isolated from each other.

[0147] Specifically, during write operations in control group A, the kernel only executes the invalidation operation on the replica pages of processes within control group A in interconnect domains 0 to 3. This removes the replica page mappings for processes within control group A and prohibits processes within control group A from creating new replicas in interconnect domains 0 to 3. The entire management process only applies to processes within control group A. Processes in interconnect domains 0 to 3 belonging to control groups B, C, and D do not have their page table mappings modified and can still access local replica pages normally. The kernel does not intercept replica creation requests from these processes, and they are completely unaffected by write operations in control group A. The version number management, replica update process, and temporary write domain lifecycle management of the four control groups are all independent of each other, each executing its own consistency management process. The completion of a tenant's write operation and the degradation of its temporary write domain will not affect the read / write domain status of other tenants.

[0148] In addition, the kernel will manage the creation and reclamation of replicas based on the resource quotas of each control group. Control group B has a replica memory quota of 512GB. When the total memory usage of replicas within control group B reaches 512GB, the kernel will suspend the creation of new replicas within control group B and simultaneously trigger the asynchronous reclamation of replicas within that control group whose access frequency is below a preset threshold. This process continues until the memory usage falls back below 400GB, at which point replica creation privileges are restored. This management process only applies to control group B and will not affect the creation and reclamation of replicas in the other three control groups.

[0149] In this embodiment, when abnormal situations such as process exit or node offline occur during system operation, corresponding exception handling procedures will be executed to ensure stable system operation and data consistency. It should be noted that in large-scale scenarios with 128 nodes, the probability of anomalies occurring in a single process or node is relatively higher; the exception handling procedures can avoid consistency risks and system resource leaks caused by abnormal situations.

[0150] Specifically, when the process initiating a write operation abnormally exits during the validity period of a temporary write domain, the kernel captures this event through a process exit hook function and retrieves all temporary write domains associated with that process that are currently in execution. If the temporary write domain is only associated with the abnormally exiting process, it is directly marked as invalid, the corresponding replica creation restriction is lifted, the state of the deprecated replica page is reset, its mappable attribute is restored, and the runtime resources occupied by the temporary write domain are released to avoid memory resource leaks caused by the replica page being marked as deprecated for a long time. If the temporary write domain is also associated with other normally running write operation processes, its validity is retained, and only the abnormally exiting process is removed from the write operation associated task chain, without affecting the execution of other normal write operations.

[0151] For example, if the database process initiating a write operation on node 4 exits abnormally due to a business failure during the temporary write domain's validity period, the kernel captures this event through a process exit hook, retrieves that the temporary write domain associated with this process is only bound to the abnormal process, marks the temporary write domain as invalid, removes the restriction on replica creation on nodes 0 to 7, resets the state of the deprecated replica page, releases the runtime resources occupied by the temporary write domain, and completes the exception handling. Other business processes on nodes 0 to 7 can then access this file page normally, triggering the replica creation process without being affected by the incomplete write operation of the abnormally exiting process.

[0152] In this embodiment, when a NUMA node is detected to be offline due to hardware failure, the kernel immediately triggers an update to the NUMA interconnect state matrix, removes the matrix elements corresponding to the offline node, re-executes the interconnect domain partitioning based on the updated matrix, generates a new interconnect domain partitioning result, and synchronizes it to the global directory service and the local directory agents of all online nodes. The global directory service retrieves the replica metadata of all associated offline nodes, marks the corresponding replica pages as invalid, releases the corresponding memory resources, adjusts the boundaries of all temporary write domains in the execution state, removes the offline node, and ensures that the consistency management process of the remaining online nodes can be executed normally, preventing system-wide management anomalies due to a single node failure.

[0153] Those skilled in the art will understand that the method described in the embodiments of this application can shrink the scope of consistency control in a large-scale NUMA system with 128 nodes, reducing the performance impact of write operations from all 128 nodes to 8 nodes in a single interconnect domain. The read operation performance of the 120 nodes in the read-only domain is completely unaffected by write operations, while being fully compatible with POSIX file semantics, and achieving performance improvement without modifying the business program code.

[0154] This application embodiment further provides a NUMA system page cache copy management system, such as Figure 3 As shown, the system includes: The replica page creation module identifies the target file page cache, obtains the NUMA node information of the access subject accessing the file page cache, and determines whether to create a physical replica according to at least one predefined replica generation strategy. If creation is allowed, a read-only physical page is allocated in the memory of the target NUMA node, and the data of the file page cache is copied to the physical page to form a replica page. During the access process, the page fault interrupt module first maps the replica page to the address space of the accessing subject, captures whether the target NUMA node of the process scheduling has changed, and releases the page mapping of the corresponding process when the node changes, causing the process to trigger a page fault interrupt. In the page cache replica selection module, during the memory page fault triggering process, if a file-type read page fault occurs, the module updates the mapping page of the running entity, selects a page cache replica of the current node or a nearby node according to the replica strategy, and records the association between the node and the task list. The association between the node and the task list refers to recording the mapping relationship between the NUMA node number and the corresponding access task list.

[0155] 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 method for managing page cache replicas in a NUMA system, characterized in that, Includes the following steps: Identify the target file page cache, obtain the NUMA node information of the access subject accessing the file page cache, determine whether to create a physical replica according to at least one predefined replica generation strategy, and if creation is allowed, allocate a read-only physical page in the memory of the target NUMA node, copy the data of the file page cache to the physical page, and form a replica page; During the access process, the copy page is first mapped to the address space of the accessing subject. The system detects whether the target NUMA node of the process scheduling has changed. When the node changes, the page mapping of the corresponding process is released, causing the process to trigger a page fault. In the memory page fault triggering process, if it is a file type read page fault, the mapping page of the running entity is updated, and the page cache copy of the current node or the nearest node is selected according to the copy strategy. The association relationship between the node and the task list is recorded. The association relationship between the node and the task list refers to the mapping relationship between the NUMA node number and the corresponding access task list.

2. The NUMA system page cache copy management method according to claim 1, characterized in that, The step of determining whether to create a physical replica based on at least one predefined replica generation strategy includes: Based on the policy settings of the process accessing the file page cache, determine whether to create a physical copy of the corresponding file page cache; Based on the attributes of the file to which the file page cache belongs, determine whether to create a physical copy of the corresponding file page cache; Determine whether to allow the creation of physical replicas and the number of replicas allowed based on the memory level or system load of the target NUMA node. When the access frequency of page cache replicas on a NUMA node is lower than a preset threshold, a replica creation suppression window is marked for a preset duration, during which no physical replicas of the corresponding file page caches are created.

3. The NUMA system page cache copy management method according to claim 1, characterized in that, Following the step of recording the association between nodes and the task chain, the method further includes write operation processing and copy reclamation steps, which include: When a write-type page fault occurs, the replica page is marked as obsolete and awaits asynchronous recycling by the recycling thread. The access subject corresponding to the write operation is associated only with the main page, and the task chain associated with the write operation is recorded. The recycling thread retrieves the nodes recorded in the obsolete page record and the task chain based on their association with the task chain, removes the copy page mapping from the task chain, and associates the task with the main page when the task triggers a page fault again. Based on preset memory pressure parameters and the actual memory usage of the nodes, asynchronous recycling of page replicas is triggered; Determine whether to reclaim replica pages based on file settings attributes. When a file is opened in no-replica mode, reclaim all multi-replica page caches. When a file is opened in writable mode, revoke replica access permissions and asynchronously reclaim multi-node replicas. When the access frequency of a page cached copy falls below a preset threshold, copy recycling is triggered asynchronously. The recycling event is recorded and a copy creation suppression window of a preset duration is marked.

4. The NUMA system page cache copy management method according to claim 1, characterized in that, It also includes the following steps: Perform dynamic partitioning and directory service initialization of NUMA interconnection domains, and generate interconnection domain partitioning results, local directory agents and global directory services for each interconnection domain; Based on the aforementioned interconnect domain division results, the creation and metadata association management of page cache copies are performed, generating copy pages with version numbers and interconnect domain ownership information, and synchronizing the copy metadata to the corresponding directory proxy and directory service; If a write-type page fault is captured, based on the interconnect domain partitioning result and replica metadata, the lifecycle initialization of the temporary write domain is performed, generating a temporary write domain bound to the lifecycle of a single write operation, along with its corresponding lifecycle ID and timing sequence number; Using the temporary write domain as the boundary, and combining directory proxy and directory service, perform differentiated consistency control of read and write domains, and generate the result of copy cancellation in the write domain and the version update notification in the read-only domain; Based on the differentiated consistency control results and lifecycle ID, the write operation lifecycle status is detected, the temporary write domain is automatically downgraded, and the downgraded read-only domain and the rebuilt local copy page are generated. The parameters for interconnect domain partitioning, temporary write domain control, version verification, and downgrade processes are incorporated into a predefined policy system to implement policy adaptation and replica reclamation management.

5. The NUMA system page cache copy management method according to claim 4, characterized in that, Following the step of initializing the lifecycle of the temporary write domain, a concurrent write operation arbitration step is also included: Using the target file page cache as the search criteria, detect whether there is a temporary write field in the execution state; If a temporary write field exists in the execution state, compare the timing sequence number corresponding to the current write operation with that of the existing temporary write field to generate a timing comparison result; Based on the timing comparison results, the effective temporary write domains are determined, the ineffective temporary write domains are marked as invalid, the corresponding control rules are lifted, and the write operation initiation process is associated with the main page corresponding to the effective temporary write domain.

6. The NUMA system page cache copy management method according to claim 4, characterized in that, Following the steps of dynamically partitioning the NUMA interconnect domain and initializing the directory service, the process also includes a step of dynamically updating the interconnect domain: According to the preset time period, re-collect the access latency and interconnection bandwidth data between NUMA nodes and update the NUMA interconnection status matrix; Based on the updated NUMA interconnection state matrix, the interconnection domain partitioning is re-executed to generate an updated interconnection domain partitioning result; The updated interconnect domain partitioning results are synchronized to the global directory service and local directory agent, and the interconnect domain information in the replica metadata is adjusted. When the interconnection domain partitioning result changes, the boundary of the temporary write domain in the execution state is adjusted synchronously based on the updated partitioning result.

7. The NUMA system page cache copy management method according to claim 4, characterized in that, The steps for performing differentiated consistency control of read-write domains include: Based on the boundary of the temporary write domain, the interconnect domain outside the range of the temporary write domain is marked as a read-only domain; During the effective period of the temporary write domain, the scope of the temporary write domain is used as the boundary to perform the cancellation operation on the replica pages within the domain, remove the replica page mapping of the process within the domain, and map the page table of the process that initiated the write operation only to the main page. After the main page completes the write operation, writes the data, and updates the version number, it sends a unicast version update notification to the local directory agent of the read-only domain through the global directory service, using the read-only domain as the addressing target. When a process in a read-only domain accesses a local copy page, it verifies the version number of the copy and the main page based on the version update notification stored in the local directory proxy, and performs the access or update operation of the copy page according to the verification result.

8. The NUMA system page cache copy management method according to claim 4, characterized in that, Following the step of performing the lifecycle initialization of the temporary write domain, a write operation merging step is also included, which includes: Using the target file page cache as the statistical object, the number of write operations triggered within the preset merging window is detected; if the number of write operations triggered reaches the preset threshold, the write operations within the merging window are merged into the same write operation group, and a unified lifecycle ID and temporary write domain are assigned to the write operation group. The write operation initiation process within the write operation group is included in the unified temporary write domain management scope, and the creation and degradation process of the temporary write domain is executed only once within the merge window; After the window merge ends, complete the data writing and version number update for all write operations within the write operation group, and execute the automatic degradation process of the temporary write domain based on the unified lifecycle ID.

9. The NUMA system page cache copy management method according to claim 4, characterized in that, The steps for performing the lifecycle initialization of the temporary write domain include: Get the cgroup group information of the process that initiated the write operation, and read the read / write domain configuration rules and resource quotas of the corresponding cgroup group; Based on the read / write domain configuration rules and the interconnect domain where the write operation initiating node is located, the effective scope of the temporary write domain is determined; a temporary write domain is created that is bound to the lifecycle ID and cgroup group of this write operation, and the control rules of the temporary write domain only apply to processes within the cgroup group to which it belongs; the temporary write domains corresponding to different cgroup groups are isolated from the read-only domains.

10. A NUMA system page cache copy management system, characterized in that, include: The replica page creation module identifies the target file page cache, obtains the NUMA node information of the access subject accessing the file page cache, and determines whether to create a physical replica according to at least one predefined replica generation strategy. If creation is allowed, a read-only physical page is allocated in the memory of the target NUMA node, and the data of the file page cache is copied to the physical page to form a replica page. During the access process, the page fault interrupt module first maps the replica page to the address space of the accessing subject, captures whether the target NUMA node of the process scheduling has changed, and releases the page mapping of the corresponding process when the node changes, causing the process to trigger a page fault interrupt. In the page cache replica selection module, during the memory page fault triggering process, if a file-type read page fault occurs, the module updates the mapping page of the running entity, selects a page cache replica of the current node or a nearby node according to the replica strategy, and records the association between the node and the task list. The association between the node and the task list refers to recording the mapping relationship between the NUMA node number and the corresponding access task list.

Images