Performance monitoring method and device of heterogeneous fusion memory system, electronic equipment, storage medium and program product

Abstract

The present disclosure relates to a performance monitoring method and device of a heterogeneous fusion memory system, electronic equipment, a storage medium and a program product, the heterogeneous fusion memory system comprising a plurality of memory devices, the method comprising: registering a trace point on a specified path of a kernel code, the trace point being used to trigger a memory page migration event; in a target sampling period, using a first preset tool to collect, for each memory page migration event occurring between the plurality of memory devices, an identity of a start memory device, an identity of an end memory device, and migration information; determining, according to the identity of the start memory device and the identity of the end memory device of each memory page migration event, a migration direction corresponding to the memory page migration event; for each migration direction, performing aggregation processing on the migration information of all memory page migration events corresponding to the migration direction to obtain first monitoring information of the migration direction; and outputting the first monitoring information of each migration direction of the plurality of migration directions.

Description

Technical Field

[0001] This disclosure relates to the field of operating systems, and more particularly to a method, apparatus, electronic device, storage medium, and program product for performance monitoring of a heterogeneous converged memory system. Background Technology

[0002] With the rapid development of fields such as artificial intelligence and high-performance computing, computing architecture is evolving from traditional homogeneous architectures to heterogeneous computing architectures that collaborate between CPUs (Central Processing Units) and dedicated processors such as GPUs (Graphics Processing Units), NPUs (Neural Processing Units), and DCUs (Deep Learning Units) (often referred to as XPUs). To improve data processing efficiency and simplify programming models, heterogeneous unified memory technology has emerged. This technology aims to allow CPUs and XPUs to share a unified virtual memory address space. It establishes a mapping relationship between processor local memory (i.e., physical memory) and virtual memory using memory pages (the smallest unit of memory allocated by the operating system, typically 4KB in size). Through a memory page migration mechanism, data is dynamically placed in the most frequently accessed processor local memory, thus achieving the effect of "memory following computation."

[0003] The underlying physical links and technical protocols for implementing heterogeneous unified memory are becoming increasingly diverse, such as general solutions based on the CXL (ComputeExpress Link) protocol. These technologies allow different types of memory, such as CXL memory extension devices and XPU local memory, to be integrated into a memory system visible to the operating system and possessing Non-Uniform Memory Access (NUMA) properties through specific interconnect technologies.

[0004] Currently, monitoring and management of heterogeneous converged memory primarily focuses on the bandwidth and latency of physical links, neglecting more specific migration behaviors. However, for tasks such as AI training, understanding page migration behavior is crucial for performance tuning. Currently, operations personnel often use protocol tools to monitor protocol links. Taking the CXL protocol as an example, Intel's memory monitoring tool—Intel PCM (Performance Counter Monitor)—can be used to monitor the CXL link, while tools from various XPU vendors are used to monitor the local memory status of the corresponding XPUs. This fragmented monitoring of various memory devices results in inefficiency due to tool fragmentation. Therefore, a solution capable of efficiently monitoring system memory page migration behavior is urgently needed. Summary of the Invention

[0005] This disclosure provides a method, apparatus, electronic device, storage medium, and program product for performance monitoring of heterogeneous converged memory systems, to at least address the problem of how related technologies can efficiently monitor memory page migration behavior in heterogeneous converged memory systems.

[0006] According to a first aspect of the present disclosure, a performance monitoring method for a heterogeneous fused memory system is provided. The heterogeneous fused memory system includes multiple memory devices. The performance monitoring method includes: registering trace points on a specified path in the kernel code, wherein the specified path is used to execute memory page migrations between the multiple memory devices, and a memory page migration event is triggered when the kernel code executes to the trace point; during a target sampling period, using a first preset tool, collecting the identity of the starting memory device, the identity of the ending memory device, and migration information for each memory page migration event occurring between the multiple memory devices, wherein the first preset tool is used to collect information on the kernel's memory page migration behavior; determining the migration direction corresponding to each memory page migration event based on the identity of the starting memory device and the identity of the ending memory device, wherein the migration direction represents the direction from the starting memory device to the ending memory device; for each migration direction, aggregating the migration information of all memory page migration events corresponding to that migration direction to obtain first monitoring information for that migration direction; and outputting the first monitoring information for each of the multiple migration directions.

[0007] Optionally, the migration information includes the number of migrated pages, and the first monitoring information includes the cumulative number of migrated pages; wherein, for each migration direction, the aggregation processing of the migration information of all memory page migration events corresponding to that migration direction to obtain the first monitoring information for that migration direction includes: for each migration direction, determining the sum of the number of migrated pages of all memory page migration events corresponding to that migration direction as the cumulative number of migrated pages for that migration direction.

[0008] Optionally, the performance monitoring method further includes: during the target sampling period, using a second preset tool to collect statistical data on memory page migration events occurring between the plurality of memory devices; parsing the statistical data to obtain second monitoring information, wherein the second preset tool is used to collect information on the kernel's memory page migration behavior.

[0009] Optionally, the statistical data includes the number of migrations, and the second monitoring information includes the migration frequency; wherein, the step of parsing the statistical data to obtain the second monitoring information includes: determining the migration frequency as the ratio of the number of migrations to the duration of the target sampling period.

[0010] Optionally, the plurality of memory devices includes XPU local memory and memory expansion devices; wherein, the performance monitoring method further includes: determining first performance diagnostic information when the migration frequency is greater than a frequency threshold and the cumulative number of migrated pages in the migration direction from the memory expansion device to the XPU local memory is greater than a page number threshold; and determining second performance diagnostic information when the migration frequency is greater than the frequency threshold and the cumulative number of migrated pages in the migration direction from the XPU local memory to the memory expansion device is greater than the page number threshold.

[0011] Optionally, both the first preset tool and the second preset tool include at least one of a kernel general tool and a dedicated kernel tool, wherein the kernel general tool is an infrastructure tool provided based on the kernel's native mechanism, and the dedicated kernel tool is a kernel-level tool developed based on a preset target.

[0012] Optionally, the plurality of memory devices include CPU local memory, XPU local memory, and memory expansion devices.

[0013] According to a second aspect of the present disclosure, a performance monitoring device for a heterogeneous converged memory system is provided. The heterogeneous converged memory system includes multiple memory devices. The performance monitoring device includes: a registration unit configured to register trace points on a specified path in kernel code, wherein the specified path is used to execute memory page migrations between the multiple memory devices, and a memory page migration event is triggered when the kernel code executes to the trace point; and a collection unit configured to, within a target sampling period, use a first preset tool to collect the identity of the starting memory device and the identity of the ending memory device for each memory page migration event occurring between the multiple memory devices. The system includes identification and migration information, wherein the first preset tool is used to collect information on kernel memory page migration behavior; a determination unit is configured to determine the migration direction corresponding to each memory page migration event based on the identity identifier of the starting memory device and the identity identifier of the ending memory device, wherein the migration direction represents the direction from the starting memory device to the ending memory device; an aggregation unit is configured to aggregate the migration information of all memory page migration events corresponding to each migration direction to obtain the first monitoring information of that migration direction; and an output unit is configured to output the first monitoring information of each of the multiple migration directions.

[0014] Optionally, the migration information includes the number of migrated pages, and the first monitoring information includes the cumulative number of migrated pages; the aggregation unit is further configured to determine the cumulative number of migrated pages for each migration direction by summing the number of migrated pages of all memory page migration events corresponding to that migration direction.

[0015] Optionally, the performance monitoring device further includes: a statistics unit configured to collect statistical data on memory page migration events occurring between the plurality of memory devices using a second preset tool during the target sampling period; and a parsing unit configured to parse the statistical data to obtain second monitoring information, wherein the second preset tool is used to collect information on the kernel's memory page migration behavior.

[0016] Optionally, the statistical data includes the number of migrations, and the second monitoring information includes the migration frequency; the parsing unit is further configured to determine the migration frequency as the ratio of the number of migrations to the duration of the target sampling period.

[0017] Optionally, the plurality of memory devices include XPU local memory and memory expansion devices; the performance monitoring device further includes a diagnostic unit configured to: determine first performance diagnostic information when the migration frequency is greater than a frequency threshold and the cumulative number of migrated pages in the migration direction from the memory expansion device to the XPU local memory is greater than a page number threshold; and determine second performance diagnostic information when the migration frequency is greater than the frequency threshold and the cumulative number of migrated pages in the migration direction from the XPU local memory to the memory expansion device is greater than the page number threshold.

[0018] Optionally, both the first preset tool and the second preset tool include at least one of a kernel general tool and a dedicated kernel tool, wherein the kernel general tool is an infrastructure tool provided based on the kernel's native mechanism, and the dedicated kernel tool is a kernel-level tool developed based on a preset target.

[0019] Optionally, the plurality of memory devices include CPU local memory, XPU local memory, and memory expansion devices.

[0020] According to a third aspect of the present disclosure, an electronic device is provided, comprising: at least one processor; and at least one memory storing computer-executable instructions, wherein the computer-executable instructions, when executed by the at least one processor, cause the at least one processor to perform a performance monitoring method for a heterogeneous converged memory system according to exemplary embodiments of the present disclosure.

[0021] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, wherein instructions in the computer-readable storage medium, when executed by at least one processor, cause the at least one processor to perform a performance monitoring method for a heterogeneous fused memory system according to exemplary embodiments of the present disclosure.

[0022] According to a fifth aspect of the present disclosure, a computer program product is provided, including computer instructions that, when executed by at least one processor, cause at least one processor to perform a performance monitoring method for a heterogeneous fused memory system according to exemplary embodiments of the present disclosure.

[0023] The technical solutions provided by the embodiments of this disclosure offer at least the following beneficial effects: According to the performance monitoring method, apparatus, electronic device, storage medium, and program product for heterogeneous converged memory systems disclosed herein, by pre-registering trace points on relevant paths in the kernel code, memory page migration events can be automatically triggered, allowing a first preset tool to capture the events and collect information. Based on this, by determining the migration direction of each event according to the identity identifier of the memory device related to the memory page migration event, and then aggregating the migration information collected for each event from the dimension of the migration direction, first monitoring information for each migration direction is obtained. Finally, first monitoring information for multiple different migration directions is obtained, which can clearly distinguish and statistically analyze the migration status of different migration directions, achieving efficient monitoring of memory page migration behavior in heterogeneous converged memory systems. This enables operation and maintenance personnel and tuning personnel to accurately determine the bottlenecks in data flow, providing a reference for performance optimization of special tasks such as AI training.

[0024] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0025] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0026] Figure 1 This is a flowchart of a performance monitoring method for a heterogeneous fused memory system according to an exemplary embodiment of the present disclosure.

[0027] Figure 2 This is an architecture diagram of a performance monitoring method for a heterogeneous fused memory system according to a specific embodiment of the present disclosure.

[0028] Figure 3 This is a block diagram of a performance monitoring apparatus for a heterogeneous fused memory system according to exemplary embodiments of the present disclosure.

[0029] Figure 4 This is a block diagram of an electronic device according to exemplary embodiments of the present disclosure. Detailed Implementation

[0030] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0031] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following examples do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0032] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. Another example is "performing at least one of step one and step two", which means the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0033] Hereinafter, with reference to the accompanying drawings, a performance monitoring method, apparatus, electronic device, storage medium, and program product for a heterogeneous converged memory system according to exemplary embodiments of the present disclosure will be described in detail.

[0034] Figure 1 This is a flowchart of a performance monitoring method for a heterogeneous converged memory system according to an exemplary embodiment of the present disclosure. The heterogeneous converged memory system includes multiple memory devices.

[0035] As an example, multiple memory devices may include at least two of the following: CPU local memory, XPU local memory (e.g., including but not limited to GPU local memory, NPU local memory, DCU local memory), and memory expansion devices (e.g., including but not limited to CXL memory expansion devices), thereby forming a heterogeneous fused memory system composed of multiple different types of memory devices.

[0036] Reference Figure 1 In step 101, trace points are registered on a specified path in the kernel code.

[0037] Operating systems often employ a two-tier architecture: kernel mode manages core resources, while user mode executes applications, and the two interact through system calls. Kernel code refers to the core operating system program code running in kernel mode, responsible for directly managing hardware resources, scheduling processes, and handling system calls—system-level functions. The specified path in the kernel code described here is used to execute memory page migrations between multiple memory devices, and when the kernel code execution reaches a trace point, a memory page migration event will be triggered.

[0038] This step can be considered as environment configuration and initialization before formal monitoring. By registering trace points in the relevant paths of the kernel code in advance, memory page migration events can be automatically triggered when memory page migration occurs, allowing the first preset tool to capture events and collect information in the subsequent formal monitoring phase. In this step, the user can, for example, run an initialization script, which can be used to register trace points.

[0039] As an example, tracepoints include, but are not limited to, the kernel `migrate:mm_migrate_pages` tracepoint, whose triggered memory page migration events are denoted as `migrate:mm_migrate_pages` events. In the aforementioned environment configuration and initialization steps, the initialization script can also be used to verify the existence of the tracepoint to ensure reliable information collection.

[0040] In step 102, during the target sampling period, the first preset tool is used to collect the identity of the starting memory device, the identity of the ending memory device, and the migration information for each memory page migration event that occurs between multiple memory devices.

[0041] The first preset tool is used to collect information on kernel memory page migration behavior, thereby overcoming the limitations of existing solutions that only monitor the physical link layer, and delving into the operating system kernel to achieve fine-grained monitoring of migration behavior.

[0042] It should be understood that the execution of this method is based on the fact that the functions used to drive memory page migration behavior, such as the numa_balancing (AutoNUMA) function, are enabled.

[0043] As an example, in the aforementioned environment configuration and initialization steps, the identity identifiers of each memory device can be obtained, and the kernel configuration can be checked to ensure that the aforementioned driver functions are enabled. For example, the identity identifier of each memory device can be a NUMA node ID, which can be obtained automatically by calling system commands and interfaces, or by requiring manual input from the user. For instance, the user can set CPU_NODE=0, NPU_NODE=1, and CXL_NODE=2.

[0044] In step 103, the migration direction corresponding to the memory page migration event is determined based on the identity identifier of the starting memory device and the identity identifier of the ending memory device for each memory page migration event.

[0045] The migration direction refers to the direction from the starting memory device to the ending memory device. This step determines the migration direction for each memory page migration event collected within the target sampling period, facilitating monitoring from different directional dimensions in subsequent steps.

[0046] As an example, when determining the migration direction, different granularities can be used depending on the required statistical granularity. For instance, in a system with multiple CPU local memory and multiple extended memory devices, if the statistical granularity is the type of memory device, the migration direction can be determined according to the type of the origin and destination memory devices, making the migration direction from any CPU local memory to any extended memory device the same. If the statistical granularity is the specific memory device, the migration direction can be determined according to the specific origin and destination memory devices, making the migration direction from one CPU local memory to a specified extended memory device one migration direction, and the migration direction from another CPU local memory to this specified extended memory device another migration direction. Similarly, for XPU local memory, depending on the type of dedicated processor, it may include the local memory of GPUs, NPUs, and DCUs. In this case, the migration direction can be determined separately for the local memory of each dedicated processor, or these dedicated processors' local memory can be uniformly labeled as XPU local memory, and a corresponding migration direction can be determined for it. Furthermore, combining the previous example, the migration direction can be determined according to the memory device type or the specific memory device. Of course, other reasonable methods can also be used to determine the migration direction, and this disclosure does not limit this.

[0047] In step 104, for each migration direction, the migration information of all memory page migration events corresponding to that migration direction is aggregated to obtain the first monitoring information for that migration direction.

[0048] Based on the migration direction of each memory page migration event determined in step 103, step 104 aggregates the migration information of memory page migration events belonging to the same migration direction to obtain the first monitoring information of that migration direction.

[0049] In step 104, the first monitoring information for each of the multiple migration directions is output.

[0050] This step summarizes and outputs the first monitoring information obtained in step 104 for multiple different migration directions. This information, as a whole, clearly distinguishes and statistically analyzes the migration status of different migration directions, enabling efficient monitoring of memory page migration behavior in heterogeneous converged memory systems. This allows operations and tuning personnel to accurately identify bottlenecks in data flow, such as whether the NPU's local memory is frequently fetching data from extended memory devices, or whether insufficient local NPU memory is causing frequent page swapping. This provides a reference for performance optimization of special tasks such as AI training.

[0051] As an example, you can also choose whether to output the information collected in step 102 as needed. When determining the output, you can also choose to directly output the raw information collected, or perform simple processing on the raw information before outputting it. For example, you can output the migration direction and migration information of each event. More examples will be introduced later, but we will not go into detail here.

[0052] The following section further describes a performance monitoring method for a heterogeneous fused memory system according to exemplary embodiments of the present disclosure.

[0053] Regarding migration information and the first monitoring information, optionally, the migration information includes the number of migrated pages, and the first monitoring information includes the cumulative number of migrated pages; wherein, step 103 includes: for each migration direction, determining the sum of the number of migrated pages of all memory page migration events corresponding to that migration direction as the cumulative number of migrated pages for that migration direction. By collecting and aggregating the number of migrated pages, the amount of migration data in each migration direction can be understood.

[0054] It should be understood that other migration information can also be collected according to monitoring needs, and the aggregation of migration information one or more times by migration direction dimension can be selected as needed. As an example, migration information may also include a timestamp and a delay time; the former indicates the time when the event occurred, and the latter indicates the duration of memory page migration for that event. It should also be understood that these different migration information can be collected using the same first preset tool, or different first preset tools. Furthermore, in the latter case, the same migration information may be repeatedly collected when using different first preset tools to achieve information collection from different perspectives and facilitate comparison and verification of information collected by different tools. The above tool selection and collection methods can all be configured as needed, and this disclosure does not impose any restrictions on them. Examples will be provided in the relevant sections below.

[0055] Specifically, the first preset tool may optionally include at least one of a kernel-general tool and a dedicated kernel tool. The kernel-general tool is an infrastructure-type tool provided based on the kernel's native mechanisms, while the dedicated kernel tool is a kernel-level tool developed based on a preset target. Given that current heterogeneous converged memory monitoring primarily relies on proprietary toolchains provided by various hardware vendors—for example, PCM can monitor key performance indicators such as memory bandwidth, latency, and throughput of the CXL link by reading the CPU's internal performance counter registers, helping developers analyze CXL memory usage bottlenecks—this approach is deeply tied to specific protocols and hardware counters, making it unsuitable for heterogeneous converged scenarios using other protocols or CPUs from other vendors. Therefore, the exemplary embodiments of this disclosure employ kernel-general tools to monitor memory page migration behavior at the kernel level, forming a universal monitoring solution that does not rely on specific hardware protocols or vendor-specific tools. This solution can adapt to different underlying converged technologies, thereby breaking the lock-in between protocols and vendors. This also means that the exemplary embodiments of this disclosure can shield the differences in underlying heterogeneous hardware, providing upper-level operations and optimization personnel with a unified tool and interface, allowing them to comprehensively grasp the performance status of heterogeneous converged memory without switching between tools from different vendors. Besides using general kernel tools, dedicated Linux kernel modules, also known as dedicated kernel tools, can be developed. These are kernel-level tools developed separately to achieve a predetermined goal. It should be understood that the predetermined goal is to collect information on the kernel's memory page migration behavior. Taking the migration:mm_migrate_pages tracepoint as an example, this module can register to listen for the mm_migrate_pages event and maintain a statistical table of migration behavior within the kernel. User-space programs can communicate with this kernel module to obtain statistical information by reading and writing virtual files under / sys / kernel / debug / or using netlink sockets. This approach has relatively higher implementation complexity, but also provides higher performance improvements and more accurate timing data. The choice can be made as needed, and this disclosure does not impose any restrictions.

[0056] Regarding the collection of information such as the identity of the origin and destination memory devices, the number of migrated pages, timestamps, and latency, as an example, the perf tool in the kernel's general tools can be used to collect the identity of the origin and destination memory devices, the number of migrated pages, and the timestamps. However, the perf tool cannot directly collect latency; therefore, kernel general tools based on BPF technology can be used to collect latency. It should be understood that when collecting latency, it does not directly depend on the memory page migration events triggered by the tracepoint, but the information collected can be matched with the information of memory page migration events collected using the perf tool. As an example, latency can be collected in conjunction with dynamic probe technology, which will be introduced later.

[0057] Specifically, for the perf tool, for example, within a set sampling period (e.g., 5 seconds), the perfscript command can be used to count the cumulative number of migrated pages by migration direction. The execution flow is as follows.

[0058] 1. Start a child process, execute the perf script -e migrate:mm_migrate_pages command or related interface, and let it run continuously for one or more sampling periods (sleep $SAMPLE_TIME).

[0059] 2. Print detailed information for every migration event that occurs within the sampling period in real time. Parse each line of output and extract key fields using regular expressions: nodes_from (identifier of the starting memory device, also known as the source node ID), nodes_to (identifier of the ending memory device, also known as the target node ID), and nr_succeeded (number of pages successfully migrated).

[0060] 3. Based on the previously configured CPU_NODE, NPU_NODE, and CXL_NODE, determine the direction of this migration (for example, from=2 and to=1 represents CXL→NPU), and add the page count of nr_succeeded to the corresponding direction counter to obtain the cumulative number of migrated pages for each migration direction.

[0061] In addition, after the sampling period ends, the cumulative number of migrated pages in each migration direction can be passed to the data analysis and presentation module for visualization output.

[0062] For the perf tool, the perf record command and perf script command can be used to record the precise time and detailed information of each memory page migration event. The execution flow is as follows.

[0063] 1. Execute the command `perf record -e migrate:mm_migrate_pages -a --sleep 10` repeatedly. This command will record all migration events to the `perf.data` file within 10 seconds.

[0064] 2. After 10 seconds, immediately execute the perf script command to parse the perf.data file and convert the binary event data in it into a readable text stream.

[0065] 3. Parse the text stream line by line, and for each migration event, extract its timestamp, source node ID, target node ID, and migration page number.

[0066] 4. Similarly, determine the migration direction of the event based on the configured node ID.

[0067] 5. Format and output a detailed log entry that includes a timestamp, direction marker (e.g., using a specified icon or symbol to represent CXL→NPU), and the number of migrated pages.

[0068] 6. Clean up the perf.data file to prepare for the next cycle.

[0069] In addition, similar to the cumulative number of migrated pages for each migration direction, the detailed logs output here can also be passed to the data analysis and presentation module for visualization after the sampling period ends.

[0070] It should be understood that both examples above use the perf script command in the perf tool to achieve information collection and processing from different perspectives. The former focuses on collecting the number of migrated pages and aggregating them by direction, while the latter focuses on recording the details of each migration event. These can be executed in parallel by different data collection sub-modules.

[0071] For the portion that uses BPF-based kernel general tools to collect latency, it can also be executed by a third data acquisition submodule, achieving parallel execution of the three data acquisition submodules. The following is an example flow using bpftrace (a high-level dynamic tracing language and tool based on eBPF (Extended Berkeley Packet Filter), which allows users to write short scripts to dynamically probe kernel and user-space programs, often used for custom performance monitoring and fault diagnosis). The execution flow is as follows.

[0072] 1. Use the bpftrace tool to load a specific probe script.

[0073] 2. The script uses the kprobe (Kernel Probe / Return Probe, a dynamic instrumentation mechanism in the Linux kernel that allows dynamic insertion of probe points at the entry (kprobe) and return (kretprobe) points of almost any kernel function for debugging and performance analysis) kernel dynamic probe to probe at the entry point of core memory migration functions (such as migrate_pages). When the function is called, the current nanosecond-level timestamp is recorded and stored in a hash table @start[tid] with the thread ID as the key.

[0074] 3. Simultaneously, use `kretprobe` to probe at the return point of the same function. When the function returns, retrieve the start time from the hash table based on the current thread ID.

[0075] 4. Calculate the time difference (end time - start time) and convert the result to microseconds, which is the delay time of this migration event.

[0076] 5. Obtain the number of memory pages successfully migrated in this operation from the function return value (retval).

[0077] 6. Output a record containing a timestamp, thread ID, delay time, and number of migrated pages. It should be understood that this record overlaps with the detailed log obtained using the perf tool, as both contain timestamps and number of migrated pages; therefore, a single record here can be associated with a memory page migration event in the detailed log.

[0078] As an example, in addition to probing the `migrate_pages` function, one can also probe deeper functions that interact with specific hardware, such as functions related to DMA (Direct Memory Access) mapping, or the driver entry point of the CXL controller. The latency measured in this way may be closer to the actual transmission latency of the physical link, but it may also introduce more noise; a trade-off should be made when choosing specific probe points.

[0079] It can be seen that this part of the latency data collection did not distinguish between different migration directions. Since all information is collected synchronously and in parallel, the latency can be viewed immediately when it is deemed necessary to analyze the latency based on other information. As an example, if it is desired to distinguish between different migration directions, the timestamp and migration page number of a record output here can be compared with the details of each migration event recorded by the perf tool described earlier (including timestamp, migration page number, and migration direction) to perform event association. First, determine the memory page migration event corresponding to each latency time collected, then determine the migration direction of that event as the migration direction of that latency time, and then aggregate the latency time of each migration direction from the dimension of migration direction (e.g., including but not limited to calculating at least one of the statistics such as mean, mode, and median) to obtain the latency time statistics for each migration direction. Of course, other reasonable methods can also be used, and this disclosure does not limit them.

[0080] In addition to using a first preset tool to collect migration direction-related information, the performance monitoring method according to an exemplary embodiment of this disclosure may optionally further include: during a target sampling period, using a second preset tool to collect statistical data on memory page migration events occurring between multiple memory devices; and parsing the statistical data to obtain second monitoring information. By using the second preset tool to collect overall statistical data, the dimensions of information collection can be expanded, providing richer monitoring information. As an example, the statistical data may include, but is not limited to, the number of migrations, the number of successful migrations, the number of failed migrations, and the total amount of migrated data, wherein the number of migrations is the sum of the number of successful migrations and the number of failed migrations. Correspondingly, the second monitoring information may include, but is not limited to, the migration frequency, the migration success frequency, the migration failure frequency, and the average amount of migrated data.

[0081] It should be understood that the first preset tool and the second preset tool can be the same tool or different tools. Similarly to the first preset tool, the second preset tool is used to collect information about the memory page migration behavior of the operating system kernel, and may include, for example, at least one of general kernel tools and dedicated kernel tools.

[0082] Optionally, the statistical data includes the number of migrations, and the second monitoring information includes the migration frequency; the above-mentioned parsing and processing of the statistical data to obtain the second monitoring information includes: determining the migration frequency as the ratio of the number of migrations to the duration of the target sampling period. By collecting the number of migrations within the target sampling period and calculating the migration frequency, the activity level of migration behavior can be understood.

[0083] As an example, the `perf stat` command in the `perf` tool can be used to collect migration counts. The execution flow is as follows: a subprocess is started, the `perf stat -e migrate:mm_migrate_pages` command or related interface is executed, and it is continuously run for one or more sampling periods. `perf stat` will output the total number of occurrences of the `migrate:mm_migrate_pages` event in the current period. This output is parsed to obtain the migration count, and the average number of migrations per second is calculated as the migration frequency. In the aforementioned embodiment of running different data acquisition sub-modules in parallel, this part can be executed by another data acquisition sub-module, or by one of the aforementioned data acquisition sub-modules, for example, by the data acquisition sub-module that collects the cumulative number of migrated pages, to comprehensively demonstrate the migration activity and data volume. This disclosure does not impose any limitations on this.

[0084] It should be understood that, for the aforementioned embodiment of using the perf script command in the perf tool to implement the cumulative number of migrated pages by migration direction, the number of migration events in each migration direction can also be accumulated when accumulating the number of migrated pages in each migration direction, to obtain the migration count of that migration direction, and the ratio of the migration count of that migration direction to the duration of the target sampling period can be calculated to obtain the migration frequency of that migration direction. That is, the first monitoring information also includes the migration frequency, which is also an implementation of this disclosure and falls within the protection scope of this disclosure.

[0085] As an example, the aforementioned embodiments used the perf and bpftrace tools to implement information collection. In other examples, the above functions can also be uniformly implemented based entirely on the native eBPF (Extended Berkeley Packet Filter) framework and its libraries (such as libbpf and bcc). By writing a custom eBPF program, directly mounting it to the migrate:mm_migrate_pages trace point, the filtering, counting, and delay calculation of events are completed in kernel space, and only the aggregated results are passed to the user-space program through perf_event or BPF mapping. This approach has lower performance overhead and higher flexibility.

[0086] In addition to the information collection, processing, and output described above, the performance monitoring method according to an exemplary embodiment of this disclosure may optionally further include: determining performance diagnostic information based on second monitoring information and first monitoring information for at least one migration direction. By combining the processed monitoring information to obtain performance diagnostic information, preliminary performance diagnosis can be achieved, providing a reference for manual analysis by operations and maintenance personnel and further improving monitoring efficiency.

[0087] Optionally, if the first monitoring information includes the cumulative number of migrated pages, the aforementioned determination of performance diagnostic information based on the second monitoring information and the first monitoring information for at least one migration direction includes: determining the first performance diagnostic information when the migration frequency is greater than a frequency threshold and the cumulative number of migrated pages in the migration direction from the memory expansion device to the XPU local memory is greater than a page number threshold; and determining the second performance diagnostic information when the migration frequency is greater than a frequency threshold and the cumulative number of migrated pages in the migration direction from the XPU local memory to the memory expansion device is greater than a page number threshold. A higher migration frequency indicates more frequent migrations within the target sampling period. Meanwhile, if the cumulative number of migrated pages from the memory expansion device to the XPU's local memory is large, indicating a large number of hot page upgrades, it suggests that the dataset the XPU needs to process is very large or that the XPU's local memory capacity is insufficient to accommodate the required access data. The user can be advised to consider replacing the XPU with one with a larger memory device or optimizing the running program. In this case, the first performance diagnostic information is determined, which may include at least one of the aforementioned information indicating potential problems and prompts to the user. If the cumulative number of migrated pages from the XPU's local memory to the memory expansion device is large, indicating a large number of cold page unloadings, it suggests that a large number of memory pages have migrated back from the XPU's local memory to the memory expansion device. Frequent unloading will require re-upgrading when accessing this data subsequently. The user can be advised to check if the XPU's local memory is full, consider replacing it with one with one with a larger memory device, or optimize the application's data access patterns. Similarly, the second performance diagnostic information is determined, which may include at least one of the information described in this section indicating potential problems and prompts to the user. It should be understood that the first monitoring information described above also includes the migration frequency embodiment, and more accurate diagnosis can be performed by combining the migration frequency of the corresponding migration direction. This is also an implementation method of this disclosure.

[0088] The following describes a performance monitoring method for a heterogeneous fused memory system according to a specific embodiment of this disclosure.

[0089] In this specific embodiment, the heterogeneous fused memory system includes CPU local memory (hereinafter referred to as CPU memory), XPU local memory (hereinafter referred to as XPU memory), and CXL memory. By combining kernel standard tracepoints (used to trigger memory page migration events) and dynamic probes (used to collect latency), it provides a memory monitoring scheme based on operating system kernel events that does not depend on specific hardware protocols. It collects three core indicators—migration frequency, migration event details, and migration latency—in parallel on the same system and displays them in a unified user interface, providing users with a complete view from macro trends to micro single behaviors. This enables comprehensive monitoring and in-depth performance bottleneck diagnosis of page migration behavior between CPU, XPU, and CXL memory.

[0090] like Figure 2 As shown, this specific embodiment involves three core modules: a configuration and initialization module, a data acquisition module, and a data analysis and presentation module. All modules are deployed on the monitored server node, and the overall process is as follows.

[0091] 1. Configuration and Initialization: Users first specify the NUMA node IDs corresponding to the CPU, XPU, and CXL memory in the system through the configuration and initialization module.

[0092] 2. Start monitoring: When the user starts the monitoring service, the service will start three data collection sub-modules in parallel, which are responsible for monitoring migration frequency, migration event details and migration delay respectively.

[0093] 3. Data Acquisition: Each data acquisition submodule uses the perf tool or bpftrace tool to register and listen to trace points such as migrate:mm_migrate_pages or kernel functions such as migrate_pages in the kernel.

[0094] 4. Data parsing and aggregation: When a memory page migration occurs in the kernel, the trace point and dynamic probe are triggered. The data acquisition module captures the information of the original event and determines the migration direction (such as CXL→NPU, NPU→CPU, etc.) based on the preset NUMA node ID, and performs aggregation calculations on the data.

[0095] 5. Results Presentation: The data analysis and presentation module displays metrics such as migration frequency, cumulative number of migrated pages, and single migration latency in a user-friendly manner, allowing users to perform performance analysis and problem diagnosis.

[0096] The following section provides a detailed explanation of each module and its interaction details, using the workflow as an example.

[0097] I. Environment Configuration and Initialization.

[0098] The main execution component of this section is the configuration and initialization module, and the detailed process is as follows.

[0099] 1. The user runs the initialization script.

[0100] 2. The script automatically identifies or prompts the user to manually input the NUMA node IDs corresponding to the CPU, XPU, and CXL memory in the system by calling system commands and interfaces. For example, setting CPU_NODE=0, NPU_NODE=1, and CXL_NODE=2.

[0101] 3. The script checks the kernel configuration to ensure that the numa_balancing (AutoNUMA) function is enabled, as memory page migration behavior is usually driven by it.

[0102] 4. The script verifies the existence of the kernel migration:mm_migrate_pages tracepoint, which is the basis for subsequent data collection.

[0103] II. Multi-dimensional data collection.

[0104] This part is completed by three parallel data acquisition sub-modules within the data acquisition module.

[0105] Module A: Migration Frequency and Direction Statistics Module. This module counts the total number of memory migrations within a set sampling period (e.g., 5 seconds), and counts the total number of migrated pages by migration direction (the number of migration directions is determined based on the monitored nodes). The detailed process is as follows.

[0106] 1. Start a child process, execute the command perf stat -e migrate:mm_migrate_pages or related interface, and let it run continuously for one or more sampling periods (sleep $SAMPLE_TIME).

[0107] 2. When the first step ends, perf stat will output the total number of migration:mm_migrate_pages events that occurred within that period. Parse this output to obtain the number of migrations for that period, and calculate the average number of migrations per second to obtain the migration frequency for that period.

[0108] 3. At the same time, start another subprocess to execute the perf script -e migrate:mm_migrate_pages command or related interface to run one or more sampling cycles.

[0109] 4. Print detailed information for every migration event that occurs within the sampling period in real time. Parse each line of output and extract key fields using regular expressions: nodes_from (source node ID), nodes_to (target node ID), and nr_succeeded (number of pages successfully migrated).

[0110] 5. Based on the CPU_NODE, NPU_NODE, and CXL_NODE configured in step 1, determine the direction of this migration (for example, from=2 and to=1 represents CXL→NPU), and add the page number of nr_succeeded to the corresponding direction counter.

[0111] 6. After the sampling period ends, this module will transfer the cumulative page count in each direction to the data analysis and presentation module.

[0112] Module B: Migration Event Details Monitoring Module. This module records the precise time and detailed information of each memory migration event. The detailed process is as follows.

[0113] 1. Execute the command `perf record -e migrate:mm_migrate_pages -a --sleep 10` repeatedly. This command will record all migration events to the `perf.data` file within 10 seconds.

[0114] 2. After 10 seconds, immediately execute the perf script command to parse the perf.data file and convert the binary event data in it into a readable text stream.

[0115] 3. Parse the text stream line by line, and for each migration event, extract its timestamp, source node ID, target node ID, and migration page number.

[0116] 4. Similarly, determine the migration direction of the event based on the configured node ID.

[0117] 5. Format and output a detailed log containing timestamps, direction markers, and the amount of data migrated.

[0118] 6. Clean up the perf.data file to prepare for the next cycle.

[0119] Module C: Migration Latency Monitoring Module. This module monitors the time spent on a single memory page migration operation. The detailed process is as follows.

[0120] 1. Use the bpftrace tool to load a specific probe script.

[0121] 2. The script uses the kprobe kernel dynamic probe to probe at the entry point of core memory migration functions (such as migrate_pages). When the function is called, the current nanosecond-level timestamp is recorded and stored in a hash table @start[tid] with the thread ID as the key.

[0122] 3. Simultaneously, use `kretprobe` to probe at the return point of the same function. When the function returns, retrieve the start time from the hash table based on the current thread ID.

[0123] 4. Calculate the time difference (end time - start time) and convert the result to microseconds, which is the delay time for this migration.

[0124] 5. Obtain the number of memory pages successfully migrated in this operation from the function return value (retval).

[0125] 6. Output records containing timestamps, process IDs, delay times, and migration page numbers.

[0126] III. Data Analysis and Visualization.

[0127] The main execution component of this section is the data analysis and presentation module, and the detailed process is as follows.

[0128] 1. Receive aggregated data from module A and display the migration frequency in the most recent sampling period in tabular form, as well as the migration amount (in pages and MB) in multiple migration directions.

[0129] 2. Display event stream logs from module B in real time to help users understand the specific time and type of migration.

[0130] 3. Display latency data from module C in real time to help users identify whether a single migration takes too long.

[0131] 4. Provide preliminary diagnostic directions. For example, if the migration frequency is high within a sampling period, and the amount of memory pages migrating from CXL to XPU (hot page promotion) is large, it indicates that the dataset that the XPU needs to process is very large or the capacity of the XPU's local memory is insufficient to accommodate the required access data. In this case, the user may need to replace the XPU device with one with a larger memory or optimize the running program. If the amount of memory pages migrating from XPU to CXL (cold page unloading) is large and the migration is frequent, it indicates that a large number of memory pages have migrated from the XPU's local memory back to the CXL memory. Frequent unloading will cause subsequent access to this data to require a re-promotion. In this case, it is necessary to check whether the XPU's local memory is full, consider whether to replace it with an XPU device with one with a larger memory, or optimize the application's data access mode, etc.

[0132] This specific embodiment has the following advantages.

[0133] 1. This specific embodiment provides a fine-grained, directional memory migration behavior monitoring method. By capturing and analyzing kernel memory migration events, it not only counts the total frequency and latency of migration, but more importantly, it subdivides the migration behavior into multiple specific directions between CPU, XPU, and CXL memory based on the source and target NUMA node IDs of the events, and performs statistics and presentation on each direction, thereby achieving accurate quantitative analysis of key scheduling behaviors such as "hot page upgrade" and "cold page unloading".

[0134] Specifically, this embodiment provides fine-grained memory migration behavior analysis capabilities. Compared to existing technologies that can only monitor physical link bandwidth, this embodiment, through the parsing of migration events by module A, can clearly distinguish and statistically analyze migration traffic in multiple directions between CPU, XPU, and CXL memory. This allows operations and tuning personnel to accurately determine the bottlenecks in data flow, such as whether the NPU is frequently fetching data from the CXL, or whether insufficient local memory in the NPU is causing frequent swapping out. This fine-grained directional statistical analysis is something that existing technologies cannot provide.

[0135] This specific embodiment also provides multi-dimensional performance indicator correlation analysis. Through the collaborative work of modules A, B, and C, it simultaneously provides indicators in three dimensions: migration frequency, migration event details, and migration latency. This multi-dimensional indicator correlation analysis greatly improves the efficiency of problem localization. For example, when module A detects a large amount of migration in the CXL→XPU direction, it can immediately check through module C whether the latency of these migrations is too high, thereby determining whether the bottleneck is too many migrations (software scheduling problem) or too slow a single migration (hardware link bandwidth problem).

[0136] 2. This specific embodiment utilizes standard Linux kernel infrastructure such as tracepoints and kprobes, as well as common Linux kernel infrastructure like perf and eBPF, without relying on vendor-specific hardware counters or proprietary APIs. Regardless of the protocol used, as long as memory convergence ultimately manifests as page migration between NUMA nodes at the operating system level, this solution will be effective. This allows for transparent adaptation to heterogeneous converged memory systems employing different underlying physical protocols, resolving the issues of "protocol binding" and "tool fragmentation" in related technologies.

[0137] 3. This specific implementation improves the observability and tunability of heterogeneous fused memory systems. Through a unified monitoring view and intuitive directional markers, the understanding and debugging threshold of heterogeneous fused memory systems is greatly reduced. Tuning and monitoring personnel do not need in-depth knowledge of the underlying hardware details to adjust the application's data layout or task scheduling strategies based on monitoring metrics, thereby improving model training performance.

[0138] Figure 3 This is a block diagram of a performance monitoring apparatus for a heterogeneous converged memory system according to exemplary embodiments of the present disclosure. The heterogeneous converged memory system includes multiple memory devices. (Refer to...) Figure 3 The device includes a registration unit 301, a data acquisition unit 302, a determination unit 303, an aggregation unit 304, and an output unit 305.

[0139] Registration unit 301 is configured to register tracepoints on a specified path in the kernel code, where the specified path is used to perform memory page migrations between multiple memory devices. When the kernel code executes to a tracepoint, a memory page migration event will be triggered.

[0140] The acquisition unit 302 is configured to use a first preset tool to acquire the identity of the starting memory device, the identity of the ending memory device, and the migration information of each memory page migration event that occurs between multiple memory devices during the target sampling period. The first preset tool is used to acquire information about the kernel's memory page migration behavior.

[0141] The determining unit 303 is configured to determine the migration direction corresponding to the memory page migration event based on the identity of the starting memory device and the identity of the ending memory device for each memory page migration event, wherein the migration direction represents the direction from the starting memory device to the ending memory device.

[0142] The aggregation unit 304 is configured to aggregate the migration information of all memory page migration events corresponding to each migration direction to obtain the first monitoring information for that migration direction.

[0143] Output unit 305 is configured to output the first monitoring information for each of the multiple migration directions.

[0144] Optionally, the migration information includes the number of migrated pages, and the first monitoring information includes the cumulative number of migrated pages; the aggregation unit 304 is further configured to determine the cumulative number of migrated pages for each migration direction by summing the number of migrated pages of all memory page migration events corresponding to that migration direction.

[0145] Optionally, the performance monitoring device for a heterogeneous converged memory system according to an exemplary embodiment of the present disclosure further includes: a statistics unit (not shown in the figure), configured to collect statistical data on memory page migration events occurring between multiple memory devices using a second preset tool during a target sampling period; and a parsing unit (not shown in the figure), configured to parse the statistical data to obtain second monitoring information, wherein the second preset tool is used to collect information on the kernel's memory page migration behavior.

[0146] Optionally, the statistical data includes the number of migrations, and the second monitoring information includes the migration frequency; the parsing unit is also configured to determine the migration frequency as the ratio of the number of migrations to the duration of the target sampling period.

[0147] Optionally, the plurality of memory devices include XPU local memory and memory expansion devices; the performance monitoring apparatus for the heterogeneous converged memory system according to an exemplary embodiment of the present disclosure further includes a diagnostic unit (not shown in the figure), configured to determine performance diagnostic information based on second monitoring information and first monitoring information for at least one migration direction.

[0148] Optionally, the diagnostic unit is further configured to: determine first performance diagnostic information when the migration frequency is greater than a frequency threshold and the cumulative number of migrated pages in the migration direction from the memory expansion device to the XPU local memory is greater than a page number threshold; and determine second performance diagnostic information when the migration frequency is greater than a frequency threshold and the cumulative number of migrated pages in the migration direction from the XPU local memory to the memory expansion device is greater than a page number threshold.

[0149] Optionally, both the first preset tool and the second preset tool include at least one of a kernel general tool and a dedicated kernel tool, wherein the kernel general tool is an infrastructure-type tool provided based on the kernel's native mechanism, and the dedicated kernel tool is a kernel-level tool developed based on the preset target.

[0150] Optionally, the multiple memory devices include CPU local memory, XPU local memory, and memory expansion devices.

[0151] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0152] According to embodiments of this disclosure, an electronic device may be provided. Figure 4 This is a block diagram of an electronic device 400 according to an embodiment of the present disclosure. The electronic device includes at least one memory 401 and at least one processor 402. The at least one memory stores a set of computer-executable instructions 4011 and an operating system 4012. When the set of computer-executable instructions 4011 is executed by the at least one processor 402, a performance monitoring method for a heterogeneous fused memory system according to an embodiment of the present disclosure is executed.

[0153] As an example, electronic device 400 may be a PC, tablet, personal digital assistant, smartphone, or other device capable of executing the aforementioned set of instructions. Here, electronic device 400 is not necessarily a single electronic device, but may be any collection of devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. Electronic device 400 may also be part of an integrated control system or system manager, or may be configured to interconnect with a portable electronic device locally or remotely (e.g., via wireless transmission) through an interface.

[0154] In electronic device 400, processor 402 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. By way of example and not limitation, processor 402 may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, etc.

[0155] The processor 402 can execute instructions or code stored in memory, wherein memory 401 can also store data. Instructions and data can also be sent and received over a network via a network interface device, wherein the network interface device can employ any known transmission protocol.

[0156] The memory 401 may be integrated with the processor 402, for example, by placing RAM or flash memory within an integrated circuit microprocessor. Alternatively, the memory 401 may include a separate device, such as an external disk drive, a storage array, or other storage device that can be used by any database system. The memory 401 and the processor 402 may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., enabling the processor 402 to read files stored in the memory 401.

[0157] In addition, the electronic device 400 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device can be interconnected via a bus and / or network.

[0158] According to embodiments of this disclosure, a computer-readable storage medium may also be provided, wherein when instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the processor to perform the performance monitoring method for a heterogeneous fused memory system according to embodiments of this disclosure. Examples of computer-readable storage media include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the aforementioned computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, in one example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0159] According to an embodiment of this disclosure, a computer program product is provided, including computer instructions, which, when executed by a processor, implement a performance monitoring method for a heterogeneous fused memory system according to an embodiment of this disclosure.

[0160] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

[0161] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A performance monitoring method for a heterogeneous fused memory system, characterized in that, The heterogeneous fused memory system includes multiple memory devices, wherein the performance monitoring method includes: Register tracepoints on a specified path in the kernel code, wherein the specified path is used to perform memory page migrations between the plurality of memory devices, and a memory page migration event will be triggered when the kernel code executes to the tracepoint; During the target sampling period, a first preset tool is used to collect the identity of the starting memory device, the identity of the ending memory device, and the migration information for each memory page migration event that occurs between the multiple memory devices. The first preset tool is used to collect information on the kernel's memory page migration behavior. Based on the identity identifiers of the starting and ending memory devices of each memory page migration event, the migration direction corresponding to the memory page migration event is determined, wherein the migration direction represents the direction from the starting memory device to the ending memory device; For each migration direction, the migration information of all memory page migration events corresponding to that migration direction is aggregated to obtain the first monitoring information for that migration direction; Output the first monitoring information for each of the multiple migration directions.

2. The performance monitoring method as described in claim 1, characterized in that, The migration information includes the number of migrated pages, and the first monitoring information includes the cumulative number of migrated pages. Specifically, for each migration direction, the migration information of all memory page migration events corresponding to that migration direction is aggregated to obtain the first monitoring information for that migration direction, including: For each migration direction, the sum of the number of migrated pages for all memory page migration events corresponding to that migration direction is determined as the cumulative number of migrated pages for that migration direction.

3. The performance monitoring method as described in claim 1, characterized in that, Also includes: During the target sampling period, a second preset tool is used to collect statistical data on memory page migration events occurring between the multiple memory devices, wherein the second preset tool is used to collect information on kernel memory page migration behavior; The statistical data is parsed and processed to obtain the second monitoring information.

4. The performance monitoring method as described in claim 3, characterized in that, The statistical data includes the number of migrations, and the second monitoring information includes the migration frequency; The step of parsing and processing the statistical data to obtain the second monitoring information includes: The ratio of the number of migrations to the duration of the target sampling period is determined as the migration frequency.

5. The performance monitoring method as described in claim 4, characterized in that, The plurality of memory devices include XPU local memory and memory expansion devices; The performance monitoring method further includes: When the migration frequency is greater than a frequency threshold and the cumulative number of migrated pages in the migration direction from the memory expansion device to the XPU local memory is greater than a page threshold, first performance diagnostic information is determined. If the migration frequency is greater than the frequency threshold and the cumulative number of migrated pages in the migration direction from the XPU local memory to the memory expansion device is greater than the page number threshold, second performance diagnostic information is determined.

6. The performance monitoring method as described in claim 3, characterized in that, Both the first preset tool and the second preset tool include at least one of a kernel general tool and a dedicated kernel tool. The kernel general tool is an infrastructure tool provided based on the kernel's native mechanism, and the dedicated kernel tool is a kernel-level tool developed based on a preset target.

7. The performance monitoring method according to any one of claims 1 to 6, characterized in that, The plurality of memory devices include CPU local memory, XPU local memory, and memory expansion devices.

8. A performance monitoring device for a heterogeneous fused memory system, characterized in that, The heterogeneous fused memory system includes multiple memory devices, wherein the performance monitoring device includes: The registration unit is configured to register tracepoints on a specified path in the kernel code, wherein the specified path is used to perform memory page migrations between the plurality of memory devices, and a memory page migration event will be triggered when the kernel code executes to the tracepoint; The acquisition unit is configured to use a first preset tool to acquire the identity of the starting memory device, the identity of the ending memory device, and the migration information of each memory page migration event that occurs between the multiple memory devices during the target sampling period. The first preset tool is used to acquire information about the kernel's memory page migration behavior. The determining unit is configured to determine the migration direction corresponding to the memory page migration event based on the identity identifier of the starting memory device and the identity identifier of the ending memory device for each memory page migration event, wherein the migration direction represents the direction from the starting memory device to the ending memory device; The aggregation unit is configured to aggregate the migration information of all memory page migration events corresponding to each migration direction to obtain the first monitoring information for that migration direction. The output unit is configured to output the first monitoring information for each of the multiple migration directions.

9. An electronic device, characterized in that, include: At least one processor; At least one memory that stores computer-executable instructions. Wherein, when the computer-executable instructions are executed by the at least one processor, the at least one processor causes the at least one processor to execute the performance monitoring method for the heterogeneous fused memory system as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the at least one processor to perform the performance monitoring method for a heterogeneous fused memory system as described in any one of claims 1 to 7.

11. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by at least one processor, they cause the at least one processor to perform the performance monitoring method for a heterogeneous fused memory system as described in any one of claims 1 to 7.

Images