Memory access delay acquisition method and device, storage medium and program product

Abstract

The embodiment of the invention provides a memory access delay obtaining method and device, a storage medium and a program product. In the memory access delay acquisition method, in an application scene of a multi-core processor, a processor core is connected to a shared memory controller through a corresponding interconnection node in an on-chip interconnection network so as to access a physical memory. A core-level memory access monitor is arranged on an interconnection node, so that delay monitoring can be carried out on a memory access request which is sent by each core and is routed to a memory controller through the interconnection node to access a physical memory. The cores of the operating system can access the memory access monitors corresponding to the cores through the driving module so as to obtain monitoring data. In the logic path, the monitoring point (the memory access monitor) is located in the routing path behind the last-stage cache, so that the time-consuming interference of the hit path of the last-stage cache can be eliminated, the memory access delay of the memory access request which does not hit the last-stage cache can be accurately counted according to the core granularity, and the memory access performance bottleneck of a single core can be conveniently positioned.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and program product for obtaining memory access latency. Background Technology

[0002] In multi-tasking deployment scenarios, to ensure the Service Level Objectives (SLOs) of different tasks, it is often necessary to use a resource scheduling agent (SLO-agent) to reasonably manage and dynamically adjust the resource usage of different tasks. For example, in mixed workload scheduling scenarios, to ensure the SLO of online tasks, it is usually necessary to use an SLO-agent to reasonably manage and dynamically adjust the resource usage of offline tasks. In this process, real-time monitoring and accurate measurement of key server performance indicators (metrics) are particularly important, among which memory access latency is especially critical.

[0003] In x86 architectures (such as Intel or AMD), PMU (Performance Monitoring Unit) events such as MEM_LOAD_RETIRED.LATENCY and OFFCORE_RESPONSE are provided to indirectly estimate the access latency from the CPU core to memory. These events reflect the combined behavior of requests traversing L1 cache, L2 cache, L3 cache, memory controller, and even accessing remote Non-Uniform Memory Access Node (NUMA) nodes via Ultra Path Interconnect (UPI) or Infinity Fabric, but they cannot isolate the access latency caused by requests being routed from the core exit through the on-chip interconnect network to the DDR controller to access physical memory. Furthermore, the general-purpose core PMU in ARM architectures typically does not provide similar core-level memory access latency events. Some solutions attempt to statistically analyze memory access latency using the DDRC PMU, but the DDRC PMU can only observe latency within the DDR physical layer. If a request is congested or queued on the path from the on-chip interconnect node to the DDR controller, for example, if a request is in... Figure 1When congestion occurs on the SNF (Slave Node-Full) or TZC (TrustZone Address Space Controller), even if the DDR itself is idle, the actual end-to-end latency may still be high, while the latency reported by the DDRC's PMU will be significantly lower, leading to distorted memory access latency monitoring results. Therefore, a new solution is needed. Summary of the Invention

[0004] This application provides a memory access latency acquisition method, device, storage medium, and program product for accurately acquiring the memory access latency of a memory access request originating from the processor core and accessing physical memory via an on-chip interconnect network.

[0005] This application provides a method for obtaining memory access latency, applied to a driver module in the kernel mode of an operating system. The operating system runs on a server platform, which includes at least one processor. Each processor integrates a memory controller and is directly connected to local physical memory. The processor includes multiple cores, which are connected to a shared last-level cache and memory controller via corresponding interconnect nodes in an on-chip interconnect network. The method includes: obtaining the kernel virtual address of a memory access monitor corresponding to any core. The memory access monitor is located on the interconnect node corresponding to the core in the on-chip interconnect network. The memory access monitor is used to: monitor the number and response latency of memory access requests issued by the core, where a memory access request refers to a request issued by the core that is routed to the memory controller via the interconnect node to access the physical memory; read monitoring data from the memory access monitor corresponding to the core based on the kernel virtual address; and calculate the memory access latency of the memory access requests issued by the core based on the monitoring data.

[0006] Optionally, obtaining the kernel virtual address of the memory access monitor corresponding to any core includes: calling the address query interface provided by the firmware of the server platform to obtain the system physical address of the memory access monitor corresponding to the core; the address query interface takes the core identifier as an input parameter, returns the system physical address of the corresponding memory access monitor, and is predefined in the system description table of the firmware; and mapping the system physical address of the memory access monitor corresponding to the core to a kernel virtual address.

[0007] Optionally, it further includes: determining a counter register allocated to the core and a configuration register corresponding to the counter register in the performance monitoring unit of the interconnect node corresponding to the core; receiving a configuration instruction for the core sent by a user-mode application; and writing a corresponding value into at least one field of the configuration register according to the configuration instruction to configure the counter register as a memory access monitor corresponding to the core.

[0008] Optionally, the at least one field includes at least one of the following: a startup enable field for starting the memory access monitor, a clear trigger field for clearing the count value of the memory access monitor, a filter activation field for activating the filtering function of the memory access monitor, and a filter condition configuration field for configuring filtering conditions. The filter condition configuration field includes at least one of the following: a partition identifier configuration field, a security attribute configuration field, a request type configuration field, and a data source configuration field.

[0009] Optionally, according to the configuration instruction, writing a corresponding value into at least one field of the configuration register includes: setting the filter activation field according to the enable filter instruction in the configuration instruction to activate the request filtering function of the memory access monitor; and configuring the partition identifier configuration field according to the first partition identifier in the configuration instruction so that the memory access monitor monitors the memory access request issued by the core corresponding to the first partition identifier, wherein the first partition identifier corresponds to the first control group.

[0010] Optionally, the first partition identifier is assigned to the first control group by the operating system; the method further includes: when the process corresponding to the first control group is scheduled to run on the core, writing the first partition identifier into the target register of the core, so that the core carries the first partition identifier when issuing a memory access request.

[0011] Optionally, the method further includes: during the operation of the performance monitoring unit, if an update instruction for the filtering conditions is received, configuring the startup enable field to 0 to stop the memory access monitor and setting the clear trigger field to 1 to clear the memory access monitor; and updating the partition identifier configuration field according to the second partition identifier in the update instruction; and configuring the startup enable field to 1 to restart the memory access monitor so that the memory access monitor monitors the access requests corresponding to the second partition identifier, the second partition identifier corresponding to the second control group.

[0012] Optionally, the monitoring data includes: the number of memory access requests matching the filter conditions in the configuration register, and the total number of clock cycles elapsed from the issuance of a memory access request matching the filter conditions in the configuration register to the receipt of a response; based on the monitoring data, calculating the memory access latency caused by the memory access request issued by the core being routed to the memory controller via the interconnect node to access the physical memory includes: calculating the memory access latency caused by a single memory access request issued by the core being routed to the memory controller via the interconnect node to access the physical memory based on the ratio of the total number of clock cycles to the number of memory access requests.

[0013] Optionally, the memory access monitor has a bit width of 64 bits and includes an overflow bit, which is used to record whether the memory access monitor has overflowed.

[0014] This application also provides a server, including: a memory and a processor; the memory is used to store one or more computer instructions; the processor is used to execute the one or more computer instructions to perform the steps in the method provided in this application.

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

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

[0017] In this embodiment, in a multi-core processor application scenario, the processor cores connect to a shared memory controller via corresponding interconnect nodes in the on-chip interconnect network to access physical memory. Core-level memory access monitors are set up on the interconnect nodes to monitor the latency of memory access requests originating from each core and routed to the memory controller via the interconnect nodes to access physical memory. The operating system kernel can access the memory access monitors corresponding to each core through the driver module to obtain monitoring data. Logically, since the monitoring point (memory access monitor) is located in the routing path after the last-level cache, the time-consuming interference of the last-level cache hit path can be eliminated. This enables precise statistics on the memory access latency of memory access requests that miss the last-level cache at the core granularity, thereby facilitating the location of memory access performance bottlenecks for individual cores. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram showing the path from the CPU core to the DDR. Figure 2 A schematic diagram of a multi-core processor sharing physical memory via an on-chip interconnect network; Figure 3 A flowchart illustrating a memory access latency acquisition method provided for an exemplary embodiment of this application; Figure 4 A schematic diagram illustrating the process of obtaining the kernel virtual address of the memory access monitor corresponding to a single core, provided as an exemplary embodiment of this application; Figure 5 This is a schematic diagram of the structure of a server provided for an exemplary embodiment of this application. Detailed Implementation

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

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

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

[0022] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0023] In a multi-core processor system, the CPU (Central Processing Unit) contains multiple independent CPU cores, a shared cache hierarchy, a memory controller, and a network-on-chip (NoC) interconnect network. For example... Figure 2 As shown, each CPU core is the basic unit for executing instructions and has its own private L1 and L2 caches to accelerate the reading of frequently accessed data. The L1 cache is typically divided into instruction and data caches; it has a small capacity and is extremely fast, while the L2 cache has a slightly larger capacity but slightly higher latency. Figure 2 As shown, each CPU core or core cluster acts as an RN-F (RequestNode-Full) accessing a designated port on the on-chip interconnect network. In modern multi-core System-on-Chip (SoC), the Last-Level Cache (LLC), such as the L3 cache in some architectures, commonly adopts a distributed architecture. This means that multiple HN-Fs (Home Node-Full) each manage a portion of the cache slice, and all slices form a unified logical address space through a consensus protocol, providing overall large-capacity sharing capabilities. When an RN-F initiates a memory access request, its internal address mapping logic (based on hashing or direct mapping of the high-order bits of the physical address) directly calculates the target HN-F; the memory access request is routed through routing nodes in the interconnect network, such as... Figure 2 The XP (Crosspoint) shown is routed to the HN-F. The HN-F queries the LLC slice it manages: if a hit occurs, it returns the data; otherwise, it requests the data from the memory subsystem via the SN-F (Slave Node). As the last-level cache before the CPU accesses main memory, LLC significantly reduces the latency and bandwidth pressure on slow main memory access.

[0024] When a memory access request from the CPU core fails to hit L1, L2, or LLC, the request is routed to the memory controller (DDRController, DDRC) via the on-chip interconnect network, such as Intel's Mesh, AMD's Infinity Fabric, or Arm's CMN. Figure 2As shown, in Arm's CMN architecture, DDRC connects to XP via a Slave Node-Full (SN-F). The SN-F integrates a Coherent Directory Block (CDB), responsible for maintaining the cache consistency state of its address space. DDRC is integrated within the CPU chip, managing communication with physical memory (DRAM) and handling DDR timing, refresh, and read / write commands. In multi-processor server systems, each CPU socket and its directly connected memory constitute a NUMA node. NUMA nodes have low latency when accessing their own memory (i.e., local memory), while cross-node access (remote memory) requires traversing the CPU interconnect bus (such as UPI), significantly increasing latency.

[0025] like Figure 2 As shown, the data path from the CPU core to physical memory is as follows: core → L1 → L2 → XP node → LLC / L3 → XP → memory controller → DRAM; if remote NUMA nodes are involved, additional interconnects between CPUs are required.

[0026] In the Linux operating system kernel, the Performance Management Controller (PMU) is used to analyze and optimize system performance. Through system calls to the `perf_event_open` interface, the PMU can be bound to a specific task (process / thread) or cgroup, allowing for targeted monitoring of performance metrics corresponding to that task or cgroup. For example, for CPU-bound PMU events (such as L1 cache hits / misses, branch prediction failures, CPU clock cycles, etc.), the Linux `perf` subsystem utilizes task context switching. It saves the PMU counter state when the task is sched-out and restores it when the task is sched-in, ensuring that the collected performance data is accurately attributed to a specific task or cgroup.

[0027] However, non-CPU-bound PMUs, such as the PMU of the memory controller, the PMU of the DDR controller (DDRC), or the PMU of the on-chip interconnect node, are typically not directly bound to the CPU core. Instead, they are used to monitor the performance metrics of system-level resources, such as the bandwidth and latency of DRAM (Double Data Rate Memory), NUMA (Non-Uniform Memory Access) nodes, DDR controllers, and interconnect networks. The statistical scope of these PMUs covers overall system-level performance data and cannot be naturally correlated to specific tasks or cgroups, making it difficult to adopt PMU / cgroup support mechanisms based on task context switching.

[0028] In some solutions, memory controller events provided by the Performance Monitoring Unit (PMU) on Intel server platforms can be used to statistically analyze DDR memory per-channel level access latency. This method can effectively reflect system-level memory access performance degradation caused by offline tasks competing for memory bandwidth in hybrid deployment scenarios (e.g., coexistence of online services and offline batch processing tasks). However, such PMU events are essentially system-level aggregate metrics of the computer hardware platform, recording the overall latency or bandwidth of all memory requests across the entire memory channel, but they cannot distinguish which specific task, process, container, or cgroup these requests originate from. Therefore, although an increase in memory latency can be observed, it is difficult to determine whether the performance degradation is caused by increased load on the online task itself or by resource contention among offline tasks. This limitation makes SLO-Agent lack fine-grained performance monitoring capabilities, thus restricting its optimization effects on resource scheduling and isolation strategies.

[0029] To address the technical problem of distorted monitoring results for memory access latency, this application provides a solution in some embodiments. The technical solutions provided by each embodiment of this application are described in detail below with reference to the accompanying drawings.

[0030] Figure 3 This is a flowchart illustrating a memory access latency acquisition method provided in an exemplary embodiment of this application. The method may include, for example: Figure 3 The steps shown are as follows: Step 301: Obtain the kernel virtual address of the memory access monitor corresponding to any core. The memory access monitor is located on the interconnect node corresponding to the core in the on-chip interconnect network. The memory access monitor is used to monitor the memory access requests issued by the core. The memory access request refers to the request issued by the core and routed to the memory controller via the interconnect node to access the physical memory.

[0031] Step 302: Read the monitoring data of the memory access monitor corresponding to the kernel based on the kernel virtual address.

[0032] Step 303: Based on the monitoring data, calculate the memory access latency caused by the memory access request issued by the core being routed to the memory controller via the interconnect node to access the physical memory.

[0033] This application's embodiments apply to a driver module in the kernel mode of an operating system. This operating system runs on a server platform, which may be based on an ARM architecture. The server platform refers to the underlying hardware and firmware architecture that constitutes the server. The server platform may include at least one processor, and any processor integrates a memory controller and is directly connected to local physical memory, such as... Figure 2 As shown. A single processor may include multiple cores, which are connected to a shared last-level cache and memory controller via corresponding interconnect nodes in an on-chip interconnect network. Memory access requests issued by a core access the shared last-level cache through the interconnect nodes. If the last-level cache is not hit, the memory access request may be routed to the memory controller via the interconnect nodes to ultimately access physical memory. The last-level cache refers to the last level of cache integrated into the CPU. In some embodiments, the last-level cache refers to the CPU's L3 cache. When the processor integrates more cache levels, the last-level cache can also be an L4 cache, L5 cache, etc. This embodiment does not impose any restrictions.

[0034] Each core in the on-chip interconnect network (IPN) contains a memory access monitor within its corresponding interconnect node, enabling core-level memory access performance monitoring. In some embodiments, the interconnect node in the IPN can be an XP node. In XP node-based IPN architectures, such as CMN (Coherent Mesh Network), each CPU core or core cluster connects as an RN-F to a designated port on a specific XP node in the IPN; this connection is fixed during the chip design phase. Based on this connection, any memory access request initiated by any core always enters the interconnect network via the same physical port on the same XP node.

[0035] Based on this, in some embodiments, for any given core, a memory access monitor corresponding to that core can be deployed on the XP node corresponding to that core in the on-chip interconnect network. For any processor, when the processor contains one or more cores, each core can correspond to a set of registers, which may include one or more memory access monitors. The memory access monitor corresponding to any core is used to monitor the number of memory access requests issued by that core and the response latency. A memory access request refers to a request issued by that core and routed to the memory controller via the on-chip interconnect network to access physical memory. That is, the memory access monitor corresponding to a single core is not used to monitor memory access requests issued by the core that have hit the L1 cache, L2 cache, or last-level cache, thereby enabling a true and accurate reflection of the memory access latency of memory access requests that originate from the core but miss the cache. In some embodiments, the set of registers corresponding to a single core may include memory access monitors for counting the number of memory access requests and memory access monitors for counting response latency.

[0036] The memory access monitor for any core can be located in any hardware component of the interconnect node corresponding to that core; this embodiment is not limited in this respect. In some optional embodiments, the memory access monitor for any core can be located in the performance monitoring unit (PMU) of the interconnect node corresponding to that core. In other optional embodiments, the memory access monitor for any core can be located in the input / output port controller or virtual channel allocator of the interconnect node corresponding to that core.

[0037] In step 301, the kernel virtual address of the memory access monitor refers to a virtual address that can be directly accessed by the driver module located in kernel mode. In this embodiment, the memory access monitor is located on the interconnect node of the hardware layer, and the driver module can map the system physical address of the memory access monitor to the kernel virtual address in order to access the memory access monitor.

[0038] The system physical address of the memory access monitor refers to the MMIO (Memory-Mapped Input / Output) mapping address of the memory access monitor in the address space of the SoC. The system physical address of the memory access monitor is statically allocated by the chip manufacturer during hardware design and is exposed through the Technical Reference Manual (TRM), Advanced Configuration and Power Interface (ACCI), or Device Tree.

[0039] Based on this, in some optional embodiments, the driver module can resolve the mapping relationship between the kernel and the memory access monitor, and query the system physical address of the memory access monitor corresponding to each kernel according to the mapping relationship and TRM, ACPI, or device tree. In other optional embodiments, the mapping relationship between the kernel and the memory access monitor can be established at the firmware layer of the operating system, and the system physical address of the memory access monitor can be reported to the operating system using a standardized method, so that the driver module does not need to resolve the mapping relationship between the kernel and the memory access monitor itself. This embodiment does not impose any restrictions.

[0040] After obtaining the system physical address of the memory access monitor corresponding to the core, the driver module can map this address to a kernel virtual address. For example, if the memory access monitor's system physical address in the SoC address space is 0x3801_0100 as defined in the chip manual, the driver module can call a memory management function, such as ioremap() in Linux, to create a page table entry that maps this system physical address to a virtual address in the kernel virtual address space, such as 0xffff_ffff_c000_1000. Then, the driver module, located in kernel mode, can read and write to the memory access monitor via pointers, just like accessing ordinary memory, without requiring special instructions.

[0041] In step 302, the driver module can read the monitoring data of the memory access monitor corresponding to the kernel virtual address. In this embodiment, the monitoring data of the memory access monitor includes: data on the monitoring of memory access requests that miss the cache issued by the kernel, including but not limited to the number of such memory access requests and the response latency. The response latency can be RTT (Round-Trip Time), which is the time span between the interconnect node issuing a memory access request and receiving a complete response.

[0042] In step 303, the driver module can calculate the memory access latency of the memory access requests issued by the core based on the monitoring data. For example, the driver module can calculate the total response latency of memory access requests that miss the cache based on the monitoring data, and calculate the average response latency of a single access request based on the total response latency and the number of memory access requests, as the memory access latency of the memory access requests issued by the core.

[0043] In this embodiment, in a multi-core processor application scenario, the processor cores connect to a shared memory controller via corresponding interconnect nodes in the on-chip interconnect network to access physical memory. Core-level memory access monitors are configured on the interconnect nodes to monitor the latency of memory access requests originating from each core and routed to the memory controller via the interconnect nodes to access physical memory. The operating system kernel accesses the memory access monitors corresponding to each core through the driver module to obtain monitoring data. Logically, since the monitoring points (memory access monitors) are located in the routing path after the last-level cache, the time-consuming interference of the last-level cache hit path can be eliminated. This enables precise statistics on the memory access latency of memory access requests that miss the last-level cache at the core granularity, thereby facilitating the location of memory access performance bottlenecks for individual cores.

[0044] In some optional embodiments, the driver module does not need to manually resolve the mapping relationship between the core and the memory monitor when obtaining the system physical address of the memory monitor corresponding to any core. Optionally, the firmware of the server platform can predefine the address lookup interface and the mapping relationship between CPU cores and memory monitors on interconnect nodes in the system description table. One way for the driver module to obtain the kernel virtual address of the memory monitor corresponding to any core may include: calling the address lookup interface provided by the firmware to obtain the system physical address of the memory monitor corresponding to the core from the system description table; then, mapping the system physical address of the memory monitor corresponding to the core to the kernel virtual address. The address lookup interface is predefined in the system description table, and the driver module can directly call the address lookup interface and pass in the core's identifier to query the system description table to obtain the system physical address of the memory monitor corresponding to the core, without needing to manually resolve the specific mapping relationship between the CPU core and the memory monitor.

[0045] In some optional embodiments, the system description table can be an ACPI table, and the address lookup interface can be a standardized interface based on the ACPI table. The firmware can define processor core topology information through the ACPI MADT (Multiple APIC Description Table), providing a core identification basis for subsequent address lookups by the memory access monitor.

[0046] Specifically, each GICC (GIC CPU Interface) structure in the MADT table contains two key fields: MPIDR (Multiprocessor Affinity Register) and Processor UID (Processor Unique Identifier). MPIDR uniquely identifies the hardware topology location of the CPU core in an ARM multi-core system, while Processor UID is a unique identifier assigned to each processor core in the ACPI specification. During the boot phase, the operating system sequentially enumerates the GICC structures in the MADT table, assigning a Logical Core ID to each processor core, thereby establishing the correspondence between the Logical Core ID and the MPIDR and Processor UID. The Processor UID will serve as the index key for subsequent memory access monitor address lookups. In this embodiment of the application applied to the Arm architecture, one physical core corresponds to one logical core. In some NUMA node-level monitoring scenarios, firmware can also establish a mapping relationship between Processor UID and PXM ID (Proximity Domain ID) through ACPI SRAT (System Resource Affinity Table). PXMID is an identifier value used in the ACPI specification to describe the NUMA topology. CPUs and memory with the same PXM ID are considered to belong to the same NUMA node. The MPIDR→PXM ID mapping relationship is used to define the topological association between NUMA nodes and the core, providing a basis for resource location in multi-node scenarios.

[0047] Based on the topology information defined in the MADT and SRAT, the operating system can establish the following correspondence during the boot phase: Logical Core ID → Processor UID → NUMA Node. The Logical Core ID is assigned by the operating system when enumerating MADT entries. The Processor UID and MPIDR are predefined by the firmware in the same GICC structure. The NUMA node affiliation is determined by the mapping relationship between Processor UID and PXM ID in the SRAT table. The Processor UID is a standardized index for exchanging memory access monitor address information between the firmware and the operating system. The firmware can report the system physical address of the memory access monitor to the operating system through a standardized interface, allowing the driver module to locate and access the memory access monitor corresponding to each core without needing to be aware of the underlying topology details. Optionally, the firmware can define independent ACPI devices for the PMUs in the on-chip interconnect nodes through the ACPI DSDT (Differentiated System Description Table) table, and define a DSM (Device-Specific Method) in this device as the address lookup interface. The DSM uses a predefined UUID as the interface identifier and the Processor UID as the query parameter to return the system physical address of the memory access monitor corresponding to the core. The DSM internally encapsulates interconnect node topology information, such as the XP node number, port number, and register base address offset to which the core is connected, encapsulating the complexity of topology resolution in the firmware layer and making it transparent to the operating system.

[0048] As shown in Figure 5, the driver module in the kernel mode of the operating system can execute the following process to obtain the kernel virtual address of the memory access monitor corresponding to a single core: S1. Enumerate all online CPU cores in the system to obtain a list of logical core IDs; S2. For any logical core ID, query the ProcessorUID corresponding to the logical core ID through the GICC structure of the MADT table, and query the PXM ID corresponding to each Processor UID through the SRAT table; S3. Search for the PMU device whose PXM attribute value matches the PXM ID in the ACPI namespace, and verify that the PMU device supports the counter address query function by calling DSM Function 0 through the predefined UUID; S4. Call the DSM method of the PMU device, pass in the UUID and Processor UID, and obtain the system physical address of the memory access monitor specific to this core from the return value; S5. Call ioremap() to map the system physical address of the memory access monitor group to the kernel virtual address; S6. Establish a mapping table from logical core ID to kernel virtual address for subsequent performance monitoring.

[0049] This implementation fully utilizes the mapping relationships and standardized DSM interface provided by the firmware at the hardware level. The driver module does not need to resolve the hardware topology itself; instead, it can directly access and read the memory access monitor via the DSM method, reducing the driver module's overhead. Furthermore, in this method, the memory latency monitoring register group is deployed in hardware such as interconnect nodes, independent of PMU events, enabling native memory latency monitoring on the ARM platform. Simultaneously, based on the ACPI standardized interface, it is also applicable to the x86 platform.

[0050] As described above, in some optional embodiments, the memory access monitor corresponding to any core may be located in the performance monitoring unit (PMU) of the interconnect node corresponding to that core. The interconnect node's PMU is a non-CPU-bound PMU, and a set of memory access latency monitoring registers corresponding to that core can be added to the PMU through hardware design. The memory access latency monitoring register set corresponding to any core includes a counter register corresponding to that core, which can be configured as the memory access monitor corresponding to the core, enabling the interconnect node's PMU to achieve core-level memory access performance monitoring.

[0051] Optionally, the memory access latency monitoring register group corresponding to any core further includes a configuration register, which is used to configure the counter register corresponding to that core. The driver module, acting as a bridge between the PMU and user space, can also configure the counter register corresponding to each core individually by writing to the configuration register, thus obtaining the memory access monitor for each core. In some embodiments, the offset between the system physical address of the memory access monitor and the system physical address of its corresponding configuration register can be fixed on the PMU. After mapping the system physical addresses of the memory access monitor and the configuration register to the kernel virtual address space using ioremap(), the offset between their corresponding kernel virtual addresses remains unchanged. Based on this, after obtaining the kernel virtual address of the memory access monitor, the driver module can obtain the kernel virtual address of the configuration register according to this offset, so as to write configuration information related to the configuration register into the configuration register. For example, if the kernel virtual address of the memory access monitor is +0x8, the virtual address of its corresponding configuration register can be +0x0.

[0052] Optionally, for any core, the driver module can determine the count register allocated to that core and the corresponding configuration register in the PMU of the interconnect node corresponding to that core; receive configuration instructions for that core sent by the user-mode application, and write corresponding values ​​into at least one field of the configuration register according to the configuration instructions, so as to configure the count register as the memory access monitor corresponding to that core. Furthermore, each CPU core can be provided with independent memory access latency configuration capabilities, so as to flexibly and differentially configure the memory access monitors corresponding to different cores. Optionally, the at least one field includes at least one of the following: a startup enable field for starting the memory access monitor, a clear trigger field for clearing the count value of the memory access monitor, a filter activation field for activating the filtering function of the memory access monitor, and a filter condition configuration field for configuring filtering conditions. The filtering conditions refer to a set of judgment rules that enable the memory access monitor to determine whether to monitor and count the memory access request based on the metadata attributes carried by the memory access request. In this embodiment, the filter condition configuration field includes at least one of the following: a partition identifier configuration field, a security attribute configuration field, a request type configuration field, and a data source configuration field.

[0053] The partition identifier field configures the partition identifier (partid), enabling the memory access monitor to track memory access latency caused by memory access requests carrying the specified partid. The security attribute configuration field (mpam_ns) configures the Secure World or Non-Secure World identifier, allowing the memory access monitor to track memory access latency from either the Secure World or Non-Secure World. Memory access requests from the Secure World are initiated by the trusted execution environment, carry the highest privilege identifier, and have access to all memory regions. Memory access requests from the Non-Secure World are regular requests initiated by the ordinary operating system or application, have limited privileges, and are forcibly prohibited from accessing secure isolation regions by hardware. If mpam_ns=0, memory access requests from the Secure World are monitored; if mpam_ns=1, memory access requests from the Non-Secure World are monitored. The request type configuration field enables the memory access monitor to selectively monitor memory access requests based on their type. Configurable request types include, but are not limited to: Read requests (Read / Load), Write requests (Write / Store), Prefetch requests, and All requests. The data source configuration field enables the memory access monitor to filter data obtained based on the source / destination of the memory access request. For example, configurable data sources may include: local memory (local DRAM), remote NUMA node memory, or last-level cache (LLC / L3).

[0054] In some embodiments, the fields, lengths, and descriptions of the configuration register corresponding to any core may be as shown in the following table: When configuring the memory access monitor, users or relevant technical personnel can issue configuration commands for any core through a user-space application. In some embodiments, this application can be the Perf tool, which can transmit configuration commands to the driver module through an extended PMU event interface. After receiving the configuration commands, the driver module can configure the configuration registers corresponding to different cores according to the configuration commands for each core. When the enable field in the configuration register corresponding to any core is set to 1, the memory access monitor for that core begins to count the number of memory access requests issued by that core and the latency experienced by each memory access request from issuance to receipt of a response. When the partid_en field in the configuration register corresponding to any core is set to 1, the memory access monitor for that core can count the number of memory access requests issued by that core and the latency experienced by each memory access request from issuance to receipt of a response based on partid_cgf, mpam_ns, req_type, and detasrc_type. When the partid_en field in the configuration register corresponding to any core is not set to 1, the memory access monitor for that core does not need to count the memory access requests issued by that core according to the filtering conditions.

[0055] Optionally, in scenarios where memory access requests issued to any core are filtered according to control groups (cgroups), users or relevant technical personnel can specify the partition identifier (partid) corresponding to the cgroup through user-space applications. Different cgroups can correspond to different tasks; a single task can be a single process, a group of microservices, a container, a virtual machine, or a user session. For example, in some cloud computing scenarios, cgroups can be used as the underlying mechanism to partition and limit resources when performing multi-tenant isolation of containers and virtual machines.

[0056] In some optional embodiments, when multiple cgroups of tasks run on the same CPU core, the operating system scheduler can schedule processes from different cgroups to execute on that core in turn. Different cgroups correspond to different partids. After the driver module writes the partid as a filtering condition through the configuration register corresponding to the core, the memory access monitor corresponding to that core only counts memory access requests carrying that partid, thereby achieving cgroup-level memory access latency isolation statistics for a single core at the hardware level. In other embodiments, in scenarios where the operating system allocates exclusive access to a core to a certain cgroup through the cpuset mechanism, only a single fixed cgroup of processes runs on the core. In this case, the counter corresponding to the core does not need to be configured with a partid; it can directly collect the memory access latency data of the cpuset bound to that cgroup to obtain the memory access latency of that cgroup. This is beneficial for achieving cgroup-based memory access latency collection in scenarios where partid cannot be configured.

[0057] To distinguish it from the control groups and partition identifiers mentioned later, it is described here as a first control group and its corresponding first partition identifier. Configuration instructions may include: an enable filter instruction and the first partition identifier corresponding to the first control group. When the driver module writes the corresponding value to at least one field of the configuration register according to the configuration instruction, it can set the filter activation field according to the enable filter instruction in the configuration instruction to activate the request filtering function of the memory access monitor; and configure the partition identifier configuration field according to the first partition identifier in the configuration instruction. Furthermore, the memory access monitor can count the memory access requests issued by the core corresponding to the first partition identifier based on the first partition identifier in the configuration register.

[0058] Based on this implementation, by setting partid, the PMU on the interconnect node corresponding to each core can monitor the memory access requests of the core at the cgroup granularity. That is, in addition to monitoring the memory access latency of a single core, filtering and isolation based on cgroup granularity are further implemented on non-CPU-bound PMUs. When a cgroup is bound to a specific task, the monitoring data of the core can be aggregated according to the cgroup corresponding to the task, thereby facilitating the implementation of container / virtual machine-level memory access performance monitoring and optimizing resource scheduling and the execution efficiency of latency-sensitive tasks.

[0059] Optionally, the first partition identifier is assigned to the first control group by the operating system. When the process corresponding to the first control group is scheduled to run on this core, the driver module can write the first partition identifier into the core's target register so that the core carries the first partition identifier when issuing memory access requests. Optionally, the target register can be an MPAM (Memory System Resource Partitioning and Monitoring) register. Based on the correspondence between the first partition identifier and the first control group, and the binding relationship between the first partition identifier and the core, the memory access monitor can selectively filter memory access requests issued by this core that correspond to the first control group, thereby achieving control-level memory access performance monitoring.

[0060] In some optional embodiments, the driver module can also support dynamic modification of the filter condition configuration fields during PMU operation without affecting the overall system performance. For example, at least one of the partition identifier configuration field, security attribute configuration field, request type configuration field, and data source configuration field can be dynamically modified during PMU operation. Optionally, if an update instruction for the filter conditions is received during PMU operation, the driver module can stop the memory access monitor by writing to the configuration register, setting the start enable field in the configuration register to 0, and setting the clear trigger field to 1 to clear the memory access monitor; and updating the partition identifier configuration field according to the second partition identifier in the update instruction; then, setting the start enable field to 1 to restart the memory access monitor, so that the memory access monitor monitors the access requests corresponding to the second partition identifier, which corresponds to the second control group. The second control group is different from the first control group, and the second partition identifier is different from the first partition identifier.

[0061] In some embodiments, if the memory access monitor contains unread statistics when an update instruction for the filter conditions is received, the statistics of the memory access monitor can be read first, and then the memory access monitor can be stopped by configuring the startup enable field; subsequently, the memory access monitor can be cleared by configuring the clear trigger field. After updating the partition identifier configuration field according to the second partition identifier in the update instruction, the memory access monitor can be started by configuring the startup enable field.

[0062] Based on this implementation, the driver module can dynamically switch partition identifiers during PMU operation without stopping or resetting the memory access monitor, thereby achieving flexible monitoring of different cgroups. In particular, in some hybrid task deployment scenarios, the method of this embodiment can be used to dynamically modify the partid during PMU operation, thereby flexibly adapting to situations where task and cgroup affiliation changes frequently.

[0063] In some optional embodiments, the memory access monitor may include a request count field (flit_cnt) and a clock cycle count field (time_cycle), and each field is equipped with a dedicated overflow flag to indicate whether the corresponding field has overflowed. A flit is the basic unit of flow control and routing in NoC, and each memory access request corresponds to one or more flits. When the flit_cnt field reaches its maximum count value and continues to increment, its corresponding flit_cnt_overflow flag is set to 1. Correspondingly, when the time_cycle field overflows, its corresponding time_cycle_overflow flag is set to 1. In some optional embodiments, the memory access monitor has a bit width of 64 bits (0-63 bits) and includes an overflow bit to record whether an overflow has occurred. In this implementation, by increasing the bit width of the memory access monitor, it can support longer data acquisition and recording periods, effectively reducing the risk of overflow at high counting rates. For example, assuming the core issues approximately 62 / 100*10^9 = 620,000,000 requests per second, the time required for the `flit_cnt` field of the memory access monitor to overflow is approximately 2^63 / 620,000,000 ≈ 148,764,06511 s ≈ 471 years. Assuming the total latency of requests issued per second by the core is 62*10^9 ns, and the TCN frequency is 2 GHz, the number of clock cycles for requests issued per second by the core is 2*62*10^9. Therefore, the time required for the `time_cycle` field of the memory access monitor to overflow is approximately 2^63 / (2*62*10^9) ≈ 74,383,032.56 s ≈ 2 years. In addition, by adding overflow, it is possible to identify whether the memory access monitor has overflowed, so as to facilitate anomaly monitoring and error handling in high-frequency scenarios.

[0064] Based on the above fields, the monitoring data collected by the memory access monitor may include: the number of memory access requests that match the filter conditions in the configuration register, and the total number of clock cycles from the issuance of a memory access request to the receipt of a response.

[0065] Accordingly, the driver module calculates, based on the monitoring data, the memory access latency caused by routing a memory access request issued by the core to the memory controller via the interconnect node to access the physical memory. This can include: calculating the memory access latency caused by routing a single memory access request issued by the core to the memory controller via the interconnect node to access the physical memory based on the ratio of the total number of clock cycles to the number of memory access requests. That is, memory access latency = time_cycle / flit_cnt.

[0066] Based on this implementation, on a non-CPU-bound PMU, latency detection is accurately achieved for memory access requests from a single core that have missed the processor's last-level cache.

[0067] In some embodiments, when the memory access monitor filters memory access requests issued by the core according to the partid, the memory access latency statistics corresponding to the monitored partid can be used as the memory access latency of the cgroup to which the partid belongs, thereby realizing cgroup-level memory access performance monitoring.

[0068] In some scenarios, when it is necessary to analyze the memory access performance of NUMA nodes, the memory access latency of all cores within the NUMA node can be weighted and averaged according to the number of requests to obtain the overall memory access latency of the NUMA node, which will not be elaborated further.

[0069] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 301 to 204 can be device A; or the execution subject of steps 301 and 302 can be device A, and the execution subject of step 303 can be device B; and so on.

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

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

[0072] Figure 5 This illustration shows a structural diagram of a server provided in an exemplary embodiment of this application. The server can be implemented as a conventional server, a cloud server, or a server array, etc. Figure 5 As shown, the server includes: a memory 501, a processor 502, and a communication component 503.

[0073] The server runs an operating system and includes at least one processor 502. Each processor 502 integrates a memory controller and is directly connected to local physical memory. The processor 502 includes multiple cores, which are connected to a shared final cache and memory controller through corresponding interconnect nodes in an on-chip interconnect network.

[0074] Memory 501 is used to store computer programs and can be configured to store various other data to support operations on the server. Examples of this data include instructions for any application or method used to operate on the server, data structures, contact data, phone book data, messages, pictures, videos, etc. In some embodiments, the computer programs stored in memory 501 include programs corresponding to driver modules in the kernel mode of the operating system.

[0075] Processor 502, coupled to memory 501, is used to execute computer programs in memory 501 for: obtaining the kernel virtual address of a memory access monitor corresponding to any core, the memory access monitor being located on an interconnect node corresponding to the core in the on-chip interconnect network, the memory access monitor being used to: monitor the number and response latency of memory access requests issued by the core, the memory access request being a request issued by the core and routed to the memory controller via the interconnect node to access the physical memory; reading monitoring data from the memory access monitor corresponding to the core based on the kernel virtual address; and calculating the memory access latency of the memory access requests issued by the core based on the monitoring data.

[0076] Optionally, when the processor 502 obtains the kernel virtual address of the memory access monitor corresponding to any core, it specifically performs the following: calls the address query interface provided by the firmware of the server platform to obtain the system physical address of the memory access monitor corresponding to the core; the address query interface takes the core identifier as an input parameter, returns the system physical address of the corresponding memory access monitor, and is predefined in the system description table of the firmware; and maps the system physical address of the memory access monitor corresponding to the core to a kernel virtual address.

[0077] Optionally, the processor 502 is further configured to: determine, in the performance monitoring unit of the interconnect node corresponding to the core, a counter register allocated to the core and a configuration register corresponding to the counter register; receive a configuration instruction for the core sent by a user-mode application; and, according to the configuration instruction, write a corresponding value into at least one field of the configuration register to configure the counter register as a memory access monitor corresponding to the core.

[0078] Optionally, the at least one field includes at least one of the following: a startup enable field for starting the memory access monitor, a clear trigger field for clearing the count value of the memory access monitor, a filter activation field for activating the filtering function of the memory access monitor, and a filter condition configuration field for configuring filtering conditions. The filter condition configuration field includes at least one of the following: a partition identifier configuration field, a security attribute configuration field, a request type configuration field, and a data source configuration field.

[0079] Optionally, when the processor 502 writes a corresponding value to at least one field of the configuration register according to the configuration instruction, it is specifically configured to: set the filter activation field according to the enable filter instruction in the configuration instruction to activate the request filtering function of the memory access monitor; and configure the partition identifier configuration field according to the first partition identifier in the configuration instruction so that the memory access monitor monitors the memory access request issued by the core corresponding to the first partition identifier, wherein the first partition identifier corresponds to the first control group.

[0080] Optionally, the first partition identifier is assigned to the first control group by the operating system; the processor 502 is further configured to: write the first partition identifier into the target register of the core when the process corresponding to the first control group is scheduled to run on the core, so that the core carries the first partition identifier when issuing a memory access request in user mode.

[0081] Optionally, the processor 502 is further configured to: during the operation of the performance monitoring unit, if an update instruction for the filtering conditions is received, configure the startup enable field to 0 to stop the memory access monitor and set the clear trigger field to 1 to clear the memory access monitor; and update the partition identifier configuration field according to the second partition identifier in the update instruction; configure the startup enable field to 1 to restart the memory access monitor, so that the memory access monitor monitors the access request corresponding to the second partition identifier, the second partition identifier corresponding to the second control group.

[0082] Optionally, the monitoring data includes: the number of memory access requests matching the filter conditions in the configuration register, and the total number of clock cycles elapsed from the issuance of a memory access request matching the filter conditions in the configuration register to the receipt of a response; when the processor 502 calculates the memory access latency caused by a memory access request issued by the core being routed to the memory controller via the interconnect node to access the physical memory based on the monitoring data, it is specifically used to: calculate the memory access latency caused by a single memory access request issued by the core being routed to the memory controller via the interconnect node to access the physical memory based on the ratio of the total number of clock cycles to the number of memory access requests.

[0083] Optionally, the memory access monitor has a bit width of 64 bits and includes an overflow bit, which is used to record whether the memory access monitor has overflowed.

[0084] Furthermore, such as Figure 5 As shown, the server also includes other components such as a power supply component 504, a display component 505, and an audio component 506. Figure 5 The diagram only shows a portion of the components and does not imply that the server only includes... Figure 5 The components shown. Figure 5 In the diagram, the components within the dashed box are optional, not mandatory, and their specific requirements depend on the server's product type.

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

[0086] The communication component 503 is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G (e.g., Global System for Mobile Communications (GSM)), 3G (e.g., Wideband Code Division Multiple Access (WCDMA), 4G (e.g., Long Term Evolution (LTE)), 4G+ (e.g., LTE-Advanced (LTE-A)), or 5G (5th Generation Mobile Communication Technology), or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

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

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

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

[0090] In this embodiment, in a multi-core processor application scenario, the processor cores connect to a shared memory controller via corresponding interconnect nodes in the on-chip interconnect network to access physical memory. Core-level memory access monitors are configured on the interconnect nodes to monitor the latency of memory access requests originating from each core and routed to the memory controller via the interconnect nodes to access physical memory. The operating system kernel can access the memory access monitors corresponding to each core through the driver module to obtain monitoring data. Logically, since the monitoring points (memory access monitors) are located in the routing path after the last-level cache, the time-consuming interference of the last-level cache hit path can be eliminated. This enables precise statistics on the memory access latency of memory access requests that miss the last-level cache at the core granularity, thereby facilitating the identification of memory access performance bottlenecks for individual cores.

[0091] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium. Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

[0092] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, product, or apparatus that includes said element.

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

Claims

1. A memory access latency fetching method, characterized in that, A driver module applied in the kernel mode of an operating system, the operating system running on a server platform, the server platform including at least one processor, any processor integrating a memory controller and directly connected to local physical memory, the processor including multiple cores, the multiple cores being connected to a shared final cache and memory controller through corresponding interconnect nodes in an on-chip interconnect network; the method includes: Obtain the kernel virtual address of the memory access monitor corresponding to any core. The memory access monitor is located on the interconnect node corresponding to the core in the on-chip interconnect network. The memory access monitor is used to monitor the number of memory access requests issued by the core and the response latency. The memory access request refers to the request issued by the core, which is routed to the memory controller via the interconnect node to access the physical memory. Based on the kernel virtual address, read the monitoring data of the memory access monitor corresponding to the kernel; Based on the monitoring data, the memory access latency of the memory access request issued by the core is calculated.

2. The method according to claim 1, characterized in that, Obtain the kernel virtual address of the memory access monitor corresponding to any core, including: The address query interface provided by the firmware of the server platform is called to obtain the system physical address of the memory access monitor corresponding to the core; the address query interface takes the core identifier as input parameter and returns the system physical address of the corresponding memory access monitor, which is predefined in the system description table of the firmware; The system physical address of the memory access monitor corresponding to the core is mapped to the kernel virtual address.

3. The method according to claim 1, characterized in that, Also includes: The performance monitoring unit of the interconnect node corresponding to the core determines the counting register allocated to the core and the configuration register corresponding to the counting register; Receive configuration instructions for the core sent by user-mode applications; According to the configuration instructions, corresponding values ​​are written into at least one field of the configuration register to configure the counter register as the memory access monitor corresponding to the core.

4. The method according to claim 3, characterized in that, The at least one field includes at least one of the following: a startup enable field for starting the memory access monitor, a clear trigger field for clearing the count value of the memory access monitor, a filter activation field for activating the filtering function of the memory access monitor, and a filter condition configuration field for configuring filtering conditions. The filter condition configuration field includes at least one of the following: a partition identifier configuration field, a security attribute configuration field, a request type configuration field, and a data source configuration field.

5. The method according to claim 4, characterized in that, According to the configuration instruction, write the corresponding value to at least one field of the configuration register, including: According to the enable filtering instruction in the configuration instructions, the filter activation field is set to activate the request filtering function of the memory access monitor; and, According to the first partition identifier in the configuration instruction, the partition identifier configuration field is configured so that the memory access monitor can monitor the memory access requests issued by the core that correspond to the first partition identifier, and the first partition identifier corresponds to the first control group.

6. The method according to claim 5, characterized in that, The first partition identifier is assigned to the first control group by the operating system; The method further includes: When the process corresponding to the first control group is scheduled to run on the core, the first partition identifier is written into the target register of the core so that the core carries the first partition identifier when issuing a memory access request.

7. The method according to claim 4, characterized in that, Also includes: During the operation of the performance monitoring unit, if an update instruction for the filtering conditions is received, the start enable field is configured to 0 to stop the memory access monitor, and the clear trigger field is set to 1 to clear the memory access monitor. as well as, The partition identifier configuration field is updated according to the second partition identifier in the update instruction; Configure the startup enable field to 1 to restart the memory access monitor so that the memory access monitor monitors access requests corresponding to the second partition identifier, which corresponds to the second control group.

8. The method according to claim 4, characterized in that, The monitoring data includes: the number of memory access requests that match the filtering conditions in the configuration register, and the total number of clock cycles from the issuance of a memory access request to the receipt of a response. Based on the monitoring data, the memory access latency generated when the memory access request issued by the core is routed to the memory controller via the interconnect node to access the physical memory is calculated, including: The memory access latency is calculated based on the ratio of the total number of clock cycles to the number of memory access requests, which is used to route a single memory access request issued by the core to the memory controller via the interconnect node to access the physical memory.

9. A server, characterized in that, include: Memory and processor; The memory is used to store one or more computer instructions; The processor is configured to execute one or more computer instructions for performing the steps of the method according to any one of claims 1-8.

10. A computer-readable storage medium storing a computer program, characterized in that, When a computer program is executed by a processor, it is able to perform the steps of the method described in any one of claims 1-8.

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

Images