Methods, devices and electronic equipment for migrating memory data

Abstract

This application discloses a method, apparatus, and electronic device for migrating memory data. The method includes: obtaining a migration instruction for a target process; the target process includes at least one target thread; in response to the migration instruction, performing the following migration process on the target thread: obtaining memory data corresponding to the target thread; determining whether the memory data is exclusively occupied by the target process; if the memory data is exclusively occupied by the target process, migrating the memory data to a target memory block; if the memory data is not exclusively occupied by the target process, retaining the memory data in the original memory block.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus and electronic device for migrating memory data. Background Technology

[0002] Under a specific hardware architecture, if a process migrates between physical cores, then the memory data corresponding to the process needs to be migrated between memory blocks such as numanodes corresponding to the physical cores.

[0003] Currently, the common approach is to use migratepages, which utilizes the user-space interface exposed by the kernel to migrate all memory data corresponding to a process to a specific memory block.

[0004] However, this method of overall memory migration may increase the system load. Summary of the Invention

[0005] In view of this, this application provides a method, apparatus, and electronic device for migrating memory data, as follows:

[0006] A method for migrating memory data includes:

[0007] Obtain migration instructions for a target process; the target process contains at least one target thread;

[0008] In response to the migration instruction, the following migration process is performed on the target thread:

[0009] Obtain the memory data corresponding to the target thread;

[0010] Determine whether the memory data is exclusively occupied by the target process;

[0011] If the memory data is exclusively occupied by the target process, the memory data will be migrated to the target memory block.

[0012] If the memory data is not exclusively occupied by the target process, the memory data is retained in the original memory block.

[0013] In the above method, preferably, the memory data includes: heap data corresponding to the target thread;

[0014] Migrating the memory data to the target memory block includes:

[0015] From the heap data, select the target data that meets the migration conditions;

[0016] The target thread calls the memory page migration interface, which then migrates the target data to the target memory block.

[0017] The target memory block is the memory block corresponding to the processing core where the target thread is located after migration, and the memory block corresponding to the processing core provides a memory area for the processing core to perform data calculations.

[0018] In the above method, preferably, the migration conditions include: all data in the heap data that is exclusively accessed by the target thread; or, at least a portion of the data in the heap data that is exclusively accessed by the target thread and whose access frequency is greater than or equal to a threshold.

[0019] In the preferred embodiment of the above method, when there is only one target thread in the target process, the target memory block is the memory block corresponding to the processing core where the target thread is located after migration, and the memory block corresponding to the processing core provides a memory area for the processing core to perform data calculations.

[0020] When there are multiple target threads in the target process, the target memory block includes: the memory block corresponding to the processing core where the target threads in the target process, after migration, are located after the target number of target threads have exceeded the target number, and the target memory block is the memory block corresponding to the processing core where the target threads are located after migration.

[0021] Preferably, before migrating the memory data to the target memory block, the above method further includes:

[0022] Using the memory block mapping information of the target process, it is determined whether the memory block where the memory data is located is the same as the target memory block; the memory block mapping information includes the mapping information between the memory data and the memory block where it is located;

[0023] If the memory block containing the memory data is the same as the target memory block, the memory data is retained in the original memory block;

[0024] If the memory block containing the memory data is different from the target memory block, then the process of migrating the memory data to the target memory block is executed.

[0025] The above method, preferably, involves determining whether the memory data is exclusively occupied by the target process, including:

[0026] Obtain the data type of the memory data;

[0027] If the memory data is stack data, it is determined that the memory data is exclusively occupied by the target thread;

[0028] If the memory data is heap data, it is determined that the memory data is exclusively occupied by the target process;

[0029] If the memory data is a binary file, it is determined that the memory data is exclusively used by the target process.

[0030] If the memory data is a shared object file, determine whether the memory data is exclusively occupied by the target process based on the occupancy identifier of the shared object file.

[0031] The above method, preferably, involves migrating the memory data to the target memory block, including:

[0032] According to the data address range of the memory data, the memory page migration interface is called using a pre-deployed migration process, and the memory page migration interface migrates the memory data to the target memory block.

[0033] In the above method, preferably, the data address range of the memory data is obtained based on the address mapping information of the target process;

[0034] The address mapping information includes mapping information between the memory data and the start and end range of the virtual memory address it resides in.

[0035] A memory data migration device, comprising:

[0036] The instruction acquisition unit is used to acquire migration instructions for a target process; the target process includes at least one target thread;

[0037] A migration control unit, configured to perform the following migration process on the target thread in response to the migration instruction:

[0038] Obtain the memory data corresponding to the target thread;

[0039] Determine whether the memory data is exclusively occupied by the target process;

[0040] If the memory data is exclusively occupied by the target process, the memory data will be migrated to the target memory block.

[0041] If the memory data is not exclusively occupied by the target process, the memory data is retained in the original memory block.

[0042] An electronic device, comprising:

[0043] Memory block;

[0044] A controller is configured to receive migration instructions for a target process; the target process includes at least one target thread; and in response to the migration instructions, execute the following migration process on the target thread:

[0045] Obtain the memory data corresponding to the target thread;

[0046] Determine whether the memory data is exclusively occupied by the target process;

[0047] If the memory data is exclusively occupied by the target process, the memory data will be migrated to the target memory block.

[0048] If the memory data is not exclusively occupied by the target process, the memory data is retained in the original memory block.

[0049] By employing the above technical solution, the memory data migration method, apparatus, and electronic device provided in this application, in response to the migration instruction of the target process, for each thread in the target process, after obtaining the corresponding memory data, first determines whether it is exclusively occupied by the target process. For exclusively occupied memory data, it is migrated to the target memory block; for non-exclusively occupied memory data, it is retained in the original memory block. It is evident that this application performs the migration of exclusively occupied memory data on a per-thread basis within the process, rather than migrating the entire memory data of the process to a single memory block. This piecemeal approach reduces the burden on the system, thereby improving the efficiency of memory data migration. Attached Figure Description

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

[0051] Figure 1 A flowchart illustrating a method for migrating memory data provided in an embodiment of this application;

[0052] Figure 2 This is an example diagram of the memory pool architecture in the embodiments of this application;

[0053] Figure 3 Another flowchart of a memory data migration method provided in an embodiment of this application;

[0054] Figure 4 This is a partial flowchart of a memory data migration method provided in an embodiment of this application;

[0055] Figure 5 This is a schematic diagram of the structure of a memory data migration device provided in an embodiment of this application;

[0056] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0057] Figure 7 This is a flowchart illustrating the active migration of heap data by each thread within the embodiments of this application.

[0058] Figure 8 This is a flowchart illustrating the passive migration of .so files, .bin files, and stack data via a third-party process in a single-threaded manner, as described in this application embodiment.

[0059] Figure 9 This is a flowchart illustrating the passive migration of .so files, .bin files, and stack data via a third-party process in a multi-threaded environment, as described in this application embodiment. Detailed Implementation

[0060] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0061] refer to Figure 1 The diagram shown is a flowchart illustrating the implementation of a memory data migration method according to an embodiment of this application. This method can be applied to electronic devices with processing cores and memory blocks to facilitate process execution. Figure 2 As shown, multiple electronic devices are interconnected, and the memory blocks provided by each electronic device form a memory pool. Thus, the memory pool contains multiple memory blocks provided by the interconnected electronic devices. Each electronic device can provide one or more memory blocks, and also provides a corresponding processing core for each memory block. The storage performance of the memory blocks provided by different electronic devices may be the same or different, and the processing performance of the processing cores provided by different electronic devices may be the same or different. Specifically, the memory pool can be constructed based on multiple electronic devices using Compute Express Link (CXL). Furthermore, the processing cores and memory blocks provided by these multiple electronic devices can employ a Non-Uniform Memory Access (NUMA) architecture for memory access. Based on this, the memory data migration method in this embodiment can be applied to memory data migration scenarios between any two memory blocks in the memory pool, including memory migration between memory blocks within the same electronic device and memory migration between memory blocks in different electronic devices. The technical solution in this embodiment is mainly used to improve the efficiency of memory data migration.

[0062] Specifically, the method in this embodiment may include the following steps:

[0063] Step 101: Obtain the migration instructions for the target process.

[0064] The target process contains at least one target thread.

[0065] It's important to note that migration instructions are generated when a thread in the target process undergoes a processing core migration. The migration instructions for the target process instruct each target thread to migrate from its current processing core to a target processing core. Different target threads can migrate to the same or different processing cores. Here, the target thread can be understood as the thread that undergoes the processing core migration. For example, if the target process has five target threads: threads 1 to 5, during the migration process, threads 1, 2, and 3 are migrated to processing core a, thread 4 to processing core b, and thread 5 to processing core c. Processing cores a and c are on the same electronic device, while processing core b is on a different electronic device. The processing cores on which each target thread resides before and after the migration can be on the same electronic device or on different electronic devices.

[0066] Correspondingly, the migration instruction is also used to instruct the migration of memory data corresponding to each target thread.

[0067] Step 102: In response to the migration instruction, perform the migration process from Step 121 to Step 124 on the target thread.

[0068] In this embodiment, memory data migration is performed on a thread-by-thread basis, thereby achieving fine-grained memory data migration. Specifically, for each target thread, the migration process described in steps 121 to 124 is executed. The details are as follows:

[0069] Step 121: Obtain the memory data corresponding to the target thread.

[0070] The memory data can include: heap data, stack data, shared object files, and binary files corresponding to the target thread. Heap data refers to the data stored in the heap memory (heap space) allocated to each target thread in the target process. Stack data refers to the data stored in the stack memory (stack space) allocated to each target thread in the target process. Binary files are files in .bin format, used to store data, program code, etc. Shared object files are files in .so format, also known as shared object files or shared library files.

[0071] It should be noted that, in this embodiment, the target thread refers to the thread within the target process that requires memory data migration; that is, the target thread is the thread within the target process that has undergone processing core migration. Specifically, the information about the processing core migrated by the thread can be obtained by calling the kernel's syscall interface. Based on this, in this embodiment, when each thread in the target process is running, the syscall interface can be called to obtain the information about the processing core the thread is currently in. This information is then compared with the processing core information previously recorded by the thread. If the comparison is inconsistent, it can be determined that the thread has undergone processing core migration, and at this point, the thread is identified as the target thread.

[0072] Step 122: Determine whether the memory data is exclusively occupied by the target process. If the memory data is exclusively occupied by the target process, proceed to step 123. If the memory data is not exclusively occupied by the target process, proceed to step 124.

[0073] Step 123: Migrate the memory data to the target memory block.

[0074] Step 124: Retain the memory data in the original memory block.

[0075] The original memory block is the memory block where the original data was originally located. The target memory block is a different memory block from the original memory block.

[0076] Therefore, if the memory data is exclusively occupied by the target process, it means that migrating the memory data will not affect the normal operation of other processes. In this case, the memory data can be migrated to a target memory block that is different from the original memory block. If the memory data is not exclusively occupied by the target process, it means that other processes are simultaneously using the memory data. In this case, the memory data needs to be retained in the original memory block. This allows for memory data migration on a thread-by-thread basis while ensuring that the normal operation of other processes is not affected.

[0077] Using the above technical solution, in the memory data migration method provided in this application embodiment, in response to the migration instruction of the target process, for each thread in the target process, after obtaining the corresponding memory data, it is first determined whether it is exclusively occupied by the target process. For exclusively occupied memory data, it is migrated to the target memory block; for non-exclusively occupied memory data, it is retained in the original memory block. It can be seen that this embodiment performs the migration of exclusively occupied memory data on a per-thread basis, rather than migrating the entire memory data of the process to a single memory block. This piecemeal approach reduces the burden on the system, thereby improving the efficiency of memory data migration.

[0078] In one implementation, the memory data includes the heap data corresponding to the target thread. The heap data is the data occupied by the target thread, but it may also be occupied by other threads. That is, the data in the heap memory allocated to a thread is visible to other threads in the process and can be shared with other threads, but it will not be occupied by threads in other processes. Therefore, the heap data corresponding to the target thread is definitely exclusively occupied by the target process.

[0079] Based on this, step 123, when migrating memory data to the target memory block, can be achieved in the following way:

[0080] First, select the target data that meets the migration criteria from the heap data;

[0081] Then, the target thread calls the memory page migration interface, which then migrates the target data to the target memory block.

[0082] The target memory block is the memory block corresponding to the processing core where the target thread resides after migration, and the memory block corresponding to the processing core provides the memory area for the processing core to perform data calculations.

[0083] It's important to note that the memory block corresponding to a processing core refers to its near-end memory block at the hardware level. A processing core's near-end memory block can be considered a far-end memory block by other processing cores, and vice versa. A processing core accesses data fastest within its near-end memory block.

[0084] Based on this, in this embodiment, for heap data, the target thread can preferentially call the memory page migration interface to migrate the target data in the heap data that meets the migration conditions to the target memory block. Thus, the migration of memory data can be achieved by the target thread itself without relying on the migration process, thereby reducing the local memory space, that is, reducing the memory space consumed by the device performing the migration during the memory data migration process.

[0085] In a practical implementation, the memory page migration interface can be the movepage interface in the operating system, which can migrate memory data.

[0086] Based on the above implementation, migration conditions can include: all data in the heap, all data in the heap exclusively accessed by the target thread, or at least a portion of the heap data exclusively accessed by the target thread and accessed at a frequency greater than or equal to a threshold. The threshold can be set according to requirements. The access frequency of memory data can be recorded in the corresponding field of the memory data through data statistics. Based on this, in this embodiment, the access frequency of memory data can be read from this field, and then the memory data exclusively accessed by the target thread and accessed at a frequency greater than or equal to the threshold can be filtered out, i.e., the target data that meets the migration conditions.

[0087] It should be noted that the migration conditions can be set according to requirements. The target data in the heap data that meets the migration conditions is stored in a hot area, such as the hot memory global list pagelist. In this embodiment, the target data that meets the migration conditions in the heap data can be read in the hot area.

[0088] For example, in this embodiment, the target thread can itself migrate all the heap data or the portion of the heap data exclusively occupied by the target thread to the memory block corresponding to the processing core where the target thread resides after migration by calling the movepage interface.

[0089] For example, in this embodiment, the target thread can itself migrate the hot data in the portion of heap data exclusively occupied by the target thread to the memory block corresponding to the processing core where the target thread resides after migration by calling the movepage interface. Here, hot data in the heap data refers to data in the heap data that is accessed more or less frequently than a threshold, that is, data that is frequently accessed by the user.

[0090] As can be seen, in this embodiment, the migration of exclusive memory data is carried out on a per-thread basis within the process, rather than migrating the entire memory data of the process to a single memory block. This method of breaking down the data into smaller parts reduces the burden on the system. Furthermore, for heap data, this embodiment migrates data that meets the migration conditions to the near-end memory block, which saves near-end memory space, improves the efficiency of memory data migration, and optimizes program performance.

[0091] In one implementation, when there is only one target thread in the target process, for memory data of any data type, the target memory block is the memory block corresponding to the processing core where the target thread is located after migration. The memory block corresponding to the processing core can provide a memory area for the processing core to perform data calculations, that is, the near-end memory block of the processing core.

[0092] For example, the target process has one target thread: thread 1. Thread 1 is migrated to the processing core c. At this time, the target memory block is the memory block corresponding to processing core c, that is, the near-end memory block of processing core c. Based on this, if the memory data corresponding to thread 1 is exclusively occupied by the target process, it will be migrated to the memory block corresponding to processing core c.

[0093] When there are multiple target threads in the target process, the target memory block includes: the memory block corresponding to the processing core where the target threads in the target process are located after migration (exceeding the target number), and the target memory block is the memory block corresponding to the processing core where the target threads are located after migration.

[0094] In practice, the target memory blocks where memory data of different data types are migrated may be different. For example, for memory data of the first data type, such as binary files or shared object files, the target memory block to which the memory data of the first data type is migrated is the memory block corresponding to the processing core where the target threads in the target process, which exceed the target number, are migrated; for memory data of the second data type, such as stack data or heap data, the target memory block to which the memory data of the second data type is migrated is the memory block corresponding to the processing core where the target threads are migrated.

[0095] The target number here can be the maximum value corresponding to the number of threads running on the processing cores where each thread in the target process is migrated. For example, the number obtained by subtracting 1 from the maximum value can be set as the target number.

[0096] For example, if the target process has 5 target threads: threads 1 to 5, with threads 1, 2, and 3 migrated to processing core a, thread 4 migrated to processing core b, and thread 5 migrated to processing core c, then the target number can be 2. Based on this, for the .so and .bin files corresponding to each thread, the target memory block is the memory block corresponding to processing core a, while for the heap and stack data of each thread, the target memory block is the memory block corresponding to the processing core where each thread resides. Therefore, when migrating memory data, if the bin and so files corresponding to threads 1 through 5 are exclusively occupied by the target process, then these bin and so files exclusively occupied by the target process are migrated to the memory block corresponding to processing core a. The heap and stack data of thread 1 that meet the migration conditions are migrated to the memory block corresponding to processing core a, the heap and stack data of thread 2 that meet the migration conditions are migrated to the memory block corresponding to processing core a, the heap and stack data of thread 3 that meet the migration conditions are migrated to the memory block corresponding to processing core a, the heap and stack data of thread 4 that meet the migration conditions are migrated to the memory block corresponding to processing core b, and the heap and stack data of thread 5 that meet the migration conditions are migrated to the memory block corresponding to processing core c.

[0097] Based on the above implementation method, this embodiment may also include the following processing before step 123, such as... Figure 3 As shown:

[0098] Step 125: Using the memory block mapping information of the target process, determine whether the memory block where the memory data is located is the same as the target memory block. If the memory block where the memory data is located is the same as the target memory block, proceed to step 124; if the memory block where the memory data is located is different from the target memory block, proceed to step 123.

[0099] For example, the memory block mapping information of the target process is stored in the `numa_maps` file. The `numa_maps` file provides at least information about the memory mappings allocated to each thread in the process. The `numa_maps` file can be located in the ` / proc / pid / numa_maps` directory, where `pid` is the process identifier of the target process. By examining the `numa_maps` file, the memory allocation objects and addresses of the task can be determined. Based on this, in this embodiment, after reading the `numa_maps` file, the memory block containing the memory data corresponding to each target thread in the target process can be found within the `numa_maps` file. Thus, in this embodiment, the memory block containing the memory data corresponding to the target thread can be compared with the target memory block. If the comparison matches, then the memory data does not need to be migrated; the memory data is retained in the original memory block. In this case, the original memory block is the memory block corresponding to the processing core where the target thread will reside after migration, or the original memory block is the memory block corresponding to the processing core where more than the target number of target threads will reside after migration. If the comparison does not match, then the memory data is migrated to the target memory block. In this case, the target memory block and the original memory block are not the same memory block.

[0100] As can be seen, in this embodiment, when the target process contains multiple target threads, the memory block where the memory data is located is first determined by the memory block mapping information of the target process. This determines whether the original memory block is the memory block corresponding to the processing core where the target threads are located after migration. This avoids migrating memory data in the same memory block, thereby saving the memory resources occupied by migration and improving migration efficiency.

[0101] In one implementation, when determining whether memory data is exclusively occupied by the target process in step 122, it can be achieved in the following way: Figure 4 As shown:

[0102] Step 401: Obtain the data type of the memory data.

[0103] Memory data can include various data types such as heap data, stack data, binary files, or shared object files.

[0104] Step 402: Determine the data type of the memory data. If the memory data is stack data, proceed to step 403; if the memory data is heap data, proceed to step 404; if the memory data is a binary file, proceed to step 404; if the memory data is a shared object file, proceed to step 405.

[0105] Step 403: Determine that the memory data is exclusively occupied by the target thread.

[0106] In this context, the data type of the stack data is exclusively owned by its thread. Since it's exclusively owned by a thread, it can be determined that it's exclusively owned by the process to which the thread belongs. Similarly, the data type of the heap data is exclusively owned by the process. Therefore, for the memory data of the stack data, it can be determined that the memory data of the stack data corresponding to the target thread is exclusively owned by the target process. Based on this, in this embodiment, the memory data of these stack data types is migrated to the target memory block, such as the memory block corresponding to the processing core where the target thread resides after migration, i.e., the near-end memory block.

[0107] Step 404: Determine that the memory data is exclusively occupied by the target process.

[0108] In this embodiment, the heap data of the target thread may be occupied by one or more threads belonging to the same process, but not by other processes. Similarly, the binary file may be occupied by one or more threads belonging to the same process, but not by other processes. Therefore, for the heap data, it can be determined that the memory data of the data type corresponding to the target thread's heap data is exclusively occupied by the target process. Based on this, in this embodiment, the memory data of these heap data that meets the migration conditions is migrated to the target memory block. Similarly, for the binary file's memory data, it can be determined that the memory data of the data type corresponding to the target thread's binary file is exclusively occupied by the target process. Based on this, in this embodiment, the memory data of these binary files is migrated to the target memory block.

[0109] Step 405: Determine whether the memory data is exclusively occupied by the target process based on the shared object file's occupancy identifier.

[0110] A shared object file may be occupied by one or more processes. Each shared object file has an occupation flag, which can be numerically represented as the number of processes occupying the file. For example, if the occupation flag is 1, it indicates that the shared object file is occupied only by the process to which the thread belongs; if the occupation flag is greater than 1, it indicates that the shared object file is occupied by another process in addition to the process to which the thread belongs. Based on this, this embodiment can determine whether the shared object file's occupation flag is 1 to ascertain whether the memory data is occupied by the target process. Therefore, in this embodiment, if the shared object file's occupation flag is 1, the memory data of these shared object files is migrated to the target memory block; if the occupation flag is greater than 1, the shared object file is not migrated to avoid affecting the normal operation of the process occupying the shared object file.

[0111] As can be seen, this embodiment can determine whether memory data of different data types is exclusively occupied by the target process. This allows for the migration of memory data of different data types separately, achieving fine-grained data migration at the data dimension. This reduces migration resource consumption and improves migration efficiency while ensuring the normal operation of other processes and improving the reliability of process operation.

[0112] In one implementation, step 123, when migrating memory to the target memory block, can be achieved in the following way:

[0113] Based on the data address range of the memory data, the pre-deployed migration process calls the memory migration interface, which then migrates the memory data to the target memory block.

[0114] In this context, the migration process refers to a separate process from the target process. This migration process is a pre-deployed process primarily used for migrating memory data. Therefore, in this embodiment, memory data migration can be performed using this specially deployed migration process, thereby accelerating the migration rate and improving migration efficiency.

[0115] It should be noted that in this embodiment, various types of memory data exclusively occupied by the target process can be migrated by calling the memory migration interface using the migration process. However, for memory data of heap data type, the target thread to which the memory data belongs can be used for migration first, thereby reducing the memory resources occupied by data migration.

[0116] Based on the above implementation scheme, the data address range of memory data can be obtained from the address mapping information of the target process. The address mapping information can include the mapping information between memory data and the start and end range of the virtual memory address it resides in.

[0117] For example, address mapping information can be obtained from the maps file, which displays memory mapping information for each thread in a process. Located in the ` / proc / pid / maps` directory, the maps file contains the process ID (PID) of the process. Specifically, the memory mapping information (address mapping information) in the maps file includes the mapping relationship between the memory data corresponding to each thread in the process and the start and end points of the virtual memory addresses where this memory data resides. Based on this, in this embodiment, the start and end points of the virtual memory addresses where the memory data resides can be obtained from the address mapping information, i.e., the data address range of the memory data. Then, the migration process calls a memory migration interface such as the `movepage` interface according to this data address range. The memory migration interface reads memory data such as binary files, shared object files, stack data, and heap data according to this data address range and migrates the read memory data to the target memory block.

[0118] refer to Figure 5 This is a schematic diagram of a memory data migration device provided in an embodiment of this application. This device can be configured in an electronic device having a processing core and memory blocks to facilitate process execution, such as... Figure 2 The electronic device shown. The technical solution in this embodiment is mainly used to improve the efficiency of memory data migration.

[0119] Specifically, the device in this embodiment may include the following units:

[0120] The instruction acquisition unit 501 is used to acquire migration instructions for a target process; the target process includes at least one target thread;

[0121] Migration control unit 502 is configured to perform the following migration process on the target thread in response to the migration instruction:

[0122] Obtain the memory data corresponding to the target thread;

[0123] Determine whether the memory data is exclusively occupied by the target process;

[0124] If the memory data is exclusively occupied by the target process, the memory data will be migrated to the target memory block.

[0125] If the memory data is not exclusively occupied by the target process, the memory data is retained in the original memory block.

[0126] As can be seen from the above technical solution, in the memory data migration device provided in this application embodiment, in response to the migration instruction of the target process, for each thread in the target process, after obtaining the corresponding memory data, it is first determined whether it is exclusively occupied by the target process. For exclusively occupied memory data, it is migrated to the target memory block, and for non-exclusively occupied memory data, it is retained in the original memory block. It is evident that in this embodiment, the migration of exclusively occupied memory data is performed on a per-thread basis within the process, rather than migrating the entire memory data of the process to a single memory block. This method of breaking down the data into smaller parts reduces the burden on the system, thereby improving the efficiency of memory data migration.

[0127] In one implementation, the memory data includes: heap data corresponding to the target thread;

[0128] Specifically, when migrating the memory data to the target memory block, the migration control unit 502 is used to: filter out target data that meets the migration conditions from the heap data; use the target thread to call the memory page migration interface, and have the memory page migration interface migrate the target data to the target memory block; wherein, the target memory block is the memory block corresponding to the processing core where the target thread is located after migration, and the memory block corresponding to the processing core provides a memory area for the processing core to perform data calculations.

[0129] For example, the migration conditions include: all data in the heap data that is exclusively accessed by the target thread; or, at least a portion of the data in the heap data that is exclusively accessed by the target thread and whose access frequency is greater than or equal to a threshold.

[0130] In one implementation, when there is only one target thread in the target process, the target memory block is the memory block corresponding to the processing core where the target thread is located after migration, and the memory block corresponding to the processing core provides a memory area for the processing core to perform data calculation; when there are multiple target threads in the target process, the target memory block is the memory block corresponding to the processing core where more than a target number of target threads in the target process are located after migration.

[0131] Based on this, when there are multiple target threads in the target process, before migrating the memory data to the target memory block, the migration control unit 502 is further configured to: use the memory block mapping information of the target process to determine whether the memory block where the memory data is located is the same as the target memory block; the memory block mapping information includes the mapping information between the memory data and the memory block where it is located; if the memory block where the memory data is located is the same as the target memory block, retain the memory data in the original memory block; if the memory block where the memory data is located is different from the target memory block, execute the migration of the memory data to the target memory block.

[0132] In one implementation, when determining whether the memory data is exclusively occupied by the target process, the migration control unit 502 is specifically configured to: obtain the data type of the memory data; if the memory data is stack data, determine that the memory data is exclusively occupied by the target thread; if the memory data is heap data, determine that the memory data is exclusively occupied by the target process; if the memory data is a binary file, determine that the memory data is exclusively occupied by the target process; and if the memory data is a shared object file, determine whether the memory data is exclusively occupied by the target process based on the occupancy identifier of the shared object file.

[0133] In one implementation, when the migration control unit 502 migrates the memory data to the target memory block, it specifically performs the following: according to the data address range of the memory data, it uses a pre-deployed migration process to call the memory page migration interface, and the memory page migration interface migrates the memory data to the target memory block.

[0134] The data address range of the memory data is obtained based on the address mapping information of the target process; the address mapping information includes the mapping information between the memory data and the start and end range of the virtual memory address in which it resides.

[0135] It should be noted that the specific implementation of each unit in this embodiment can be referred to the corresponding content above, and will not be described in detail here.

[0136] refer to Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device can be... Figure 2 The electronic device shown may include the following structures:

[0137] Memory block 601, implemented through a memory, is used to store memory data;

[0138] Controller 602 is configured to receive a migration instruction for a target process; the target process includes at least one target thread; and in response to the migration instruction, execute the following migration process on the target thread:

[0139] Obtain the memory data corresponding to the target thread;

[0140] Determine whether the memory data is exclusively occupied by the target process;

[0141] If the memory data is exclusively occupied by the target process, the memory data will be migrated to the target memory block.

[0142] If the memory data is not exclusively occupied by the target process, the memory data is retained in the original memory block.

[0143] In addition, the electronic device may also include a processing core 603, which is used to run the target thread. The processing core 603 uses the memory area provided by the memory block 601 to perform data calculations in order to run the corresponding target thread.

[0144] As can be seen from the above technical solution, in the electronic device provided in this application embodiment, in response to the migration instruction of the target process, for each thread in the target process, after obtaining the corresponding memory data, it is first determined whether it is exclusively occupied by the target process. For exclusively occupied memory data, it is migrated to the target memory block, and for non-exclusively occupied memory data, it is retained in the original memory block. It is evident that in this embodiment, the migration of exclusively occupied memory data is performed on a per-thread basis within the process, rather than migrating the entire memory data of the process to a single memory block. This method of breaking down the data into smaller parts reduces the burden on the system, thereby improving the efficiency of memory data migration.

[0145] Taking a system architecture based on NUMA and CXL as an example, the technical solution of this application is described in detail below:

[0146] In system architectures built on NUMA and CXL, different processing cores, such as the Central Processing Unit (CPU), access different memory blocks, such as numanodes, at different rates, resulting in tiered memory access latency. Therefore, optimizing software performance without increasing hardware costs has become a key focus.

[0147] Currently, the migratepages interface is often used to migrate all the memory data of a process to a specific numanode. However, this migration scheme can only migrate the entire process's memory data. When the memory of a particular numanode is low, migrating the entire memory data will increase the system load and waste local memory.

[0148] To address the aforementioned issues, this application proposes an adaptive performance tuning method that combines internal and external approaches. This combination can be understood as a proactive approach combined with a passive approach, enabling rapid memory migration on demand. Specifically:

[0149] Internally: This refers to memory data migration performed by the thread (code) itself. For example, internal migration is a thread-initiated, proactive migration method, triggered and processed by the thread according to logic. Key points include:

[0150] (1) User-defined important hot memory: Based on the execution logic of its own code, a global list of hot memory, pagelist, is defined.

[0151] (2) Thread execution monitoring: After obtaining information such as CPU, numanode, and process pid of the processing core where the thread is located, the thread encapsulates and records the information. When the thread runs, it compares the CPU and numanode information with the previous information. If the numanode is different, the thread actively triggers the key memory migration in the pagelist.

[0152] (3) Thread memory migration: In order to avoid the impact of memory migration on other processes, or to cause repeated migration of shared memory between processes, when each thread migrates memory, the MPOL_MF_MOVE parameter is used in move_page to migrate only the thread's exclusive memory such as stack data and exclusive heap data, as well as the process's exclusive memory data such as bin files and so files.

[0153] It should be noted that internally, the main task is to migrate the heap area (i.e., heap data). Different threads can actively migrate the exclusive data in their heap area to the corresponding numanode as the threads are scheduled by the CPU.

[0154] External intervention: This refers to assisting a process with memory migration and tuning from a third-party perspective. A third-party process (the migration process mentioned earlier) monitors and processes the target process. In this case, it's important to distinguish whether the tuning process is single-threaded or multi-threaded. External intervention is passive but helps accelerate memory migration convergence. The following explains the single-threaded and multi-threaded scenarios separately:

[0155] 1. In a single-threaded scenario, the external thread will acquire and execute the numanode node. The memory data can be of the following data types:

[0156] (1) bin file (binary file): bin file may be shared between threads within a process, but it is definitely exclusively owned by the process. Therefore, the bin file is completely migrated.

[0157] (2) .so files (shared object files): .so files may be shared between processes. In this case, .so files with a mapmax value of 1 (i.e., .so files exclusively owned by the current process) will be completely migrated, while .so files with other mapmax values ​​will not be migrated to avoid affecting other task processes.

[0158] (3) Stack data: Stack data is memory data exclusively used by a thread. Therefore, the stack data is completely migrated.

[0159] 2. In a multi-threaded environment, memory data can be of the following types:

[0160] (1) bin file: The migration principle is: the majority of multithreads are running on the numanode, and the numanode is the memory block numanode corresponding to the processing core where the target threads exceeding the target number are located after migration.

[0161] (2) So file: Move the file with mapmax of 1 to the numanode corresponding to the processing core where most threads are migrated, while avoiding affecting the processes of other tasks.

[0162] (3) Stack data: The stack data is completely migrated to the numanode corresponding to the processing core where the thread is located after migration, i.e., the near-end numanode.

[0163] It should be noted that:

[0164] A. Regarding the exclusiveness check of .so files, since multiple threads in a process share the .so file mapping (mapmax), it is only necessary to check the mapping mapmax of the process or one of its threads.

[0165] B. Regarding stack data, since the stack data of multiple threads is independent, each thread needs to independently check the processing core it is running.

[0166] The following flowchart illustrates the migration logic of memory data, including heap data, .so files, .bin files, and stack data:

[0167] like Figure 7 The diagram shown illustrates the flowchart of the active migration of heap data by each thread internally. In this embodiment, the following process is implemented through the function interface `file` of a .so or .a file:

[0168] First, store the thread's hot data in the heap data into the hot memory global list pagelist;

[0169] Then, determine whether the thread has performed a kernel migration, i.e. whether the heap data needs to be migrated using numanodes;

[0170] If migration is required, the thread will call the move_page interface to migrate the hot data that is exclusively occupied by the thread in the pagelist to the target memory block, such as the numanode corresponding to the CPU where the thread is located after the migration.

[0171] like Figure 8 The diagram below illustrates the flowchart for the passive migration of .so files, .bin files, and stack data via a third-party process in a single-threaded environment:

[0172] First, obtain the CPU where the thread is located after migration, i.e., the target memory block mentioned above;

[0173] Then, by reading numa_maps, the system checks the numanode where the bin file is located. It determines whether the bin file is on a remote node, where the numanode where the bin file is located is different from the numanode of the CPU where the thread will be located after migration. If the bin file is not on a remote node, that is, if the bin file is on the numanode of the CPU where the thread will be located after migration (near numanode), then the bin file does not need to be migrated. If the bin file is on a remote node, the system obtains the data address range of the bin file by reading the maps, and then calls the move_page interface according to this data address range to migrate the bin file corresponding to the thread in memory, that is, to the numanode of the CPU where the thread will be located after migration.

[0174] Next, the .so files are checked, and each .so file is checked in the following way:

[0175] By reading `numa_maps`, the system checks the numanode where the .so file is located to determine if the .so file is on a remote node. Here, "on a remote node" means that the numanode where the .so file is located is different from the numanode corresponding to the CPU where the thread is located after migration. If the .so file is not on a remote node, that is, the .so file is on the numanode corresponding to the CPU where the thread is located after migration (near numanode), then the .so file does not need to be migrated. If the .so file is on a remote node, the system checks if `mapmax` is 1. If it is not 1, it means that it is not exclusively occupied by the process, so the .so file does not need to be migrated, and the system continues to check other .so files. If `mapmax` is 1, the system obtains the data address range of the .so file by reading `maps`, and then calls the `move_page` interface according to this data address range to migrate the .so file corresponding to the thread in memory, that is, to the numanode corresponding to the CPU where the thread is located after migration, until all .so files have been checked.

[0176] Finally, the stack data is checked: by reading numa_maps, the numanode where the stack data is located is checked; it is determined whether the stack data is on a remote node, which means that the numanode where the stack data is located is different from the numanode corresponding to the CPU where the thread is located after migration; if the stack data is not on a remote node, that is, the stack data is on the numanode corresponding to the CPU where the thread is located after migration (near-end numanode), then no stack data migration is required; if the stack data is on a remote node, then the data address range of the stack data is obtained by reading the maps, and then according to the data address range, the move_page interface is called to migrate the stack data corresponding to the thread in memory, that is, to the numanode corresponding to the CPU where the thread is located after migration.

[0177] like Figure 9 The diagram below illustrates the flowchart for the passive migration of .so files, .bin files, and stack data via a third-party process in a multi-threaded environment:

[0178] Obtain the CPU where most threads will reside after migration, i.e., the target memory block mentioned earlier; perform the following checks on each thread:

[0179] First, by reading numa_maps, the numanode where the bin file is located is checked; it is determined whether the bin file is in the node where a minority of threads were migrated or in the node where a majority of threads were migrated (i.e., the numanode corresponding to the CPU where a majority of threads were migrated); if the bin file is in the node where a majority of threads were migrated, then the bin file does not need to be migrated; if the bin file is in the node where a minority of threads were migrated, then the data address range of the bin file is obtained by reading the maps, and then the move_page interface is called according to the data address range to migrate the bin file corresponding to that thread in memory, that is, to the numanode corresponding to the CPU where the thread was migrated;

[0180] Next, the .so files are checked, and each .so file is checked in the following way:

[0181] By reading `numa_maps`, the system checks the `numanode` where the `.so` file is located. It determines whether the `.so` file is in the node where a minority of threads migrate or the node where a majority of threads migrate (i.e., the `numanode` corresponding to the CPU where a majority of threads migrate). If the `.so` file is in the node where a majority of threads migrate, then it doesn't need to be migrated. If the `.so` file is in the node where a minority of threads migrate, it checks if `mapmax` is 1. If it's not 1, it means the file isn't exclusively used by the process, so it doesn't need to be migrated, and the system continues checking other `.so` files. If `mapmax` is 1, it reads `maps` to obtain the data address range of the `.so` file, and then calls the `move_page` interface to migrate the `.so` file corresponding to that thread in memory, i.e., to the `numanode` corresponding to the CPU where the thread migrates. This process continues until all `.so` files have been checked.

[0182] Finally, stack data inspection begins, performing the following checks on each thread:

[0183] By reading `numa_maps`, the system checks the `numanode` where the stack data resides. It then determines if the stack data is on a remote node, meaning the `numanode` where the stack data is located is different from the `numanode` corresponding to the CPU the thread will reside on after migration. If the stack data is not on a remote node, no migration is needed, and the system continues checking the next thread. If the stack data is on a remote node, the system obtains the data address range of the stack data by reading the maps, and then calls the `move_page` interface according to this address range to migrate the stack data corresponding to that thread in memory, i.e., to the `numanode` corresponding to the CPU the thread will reside on after migration, until all threads have been checked.

[0184] In summary, the technical solution adopted in this application has the following advantages:

[0185] 1. By adopting an active migration method internally, instead of the numa balance mode, the process can be guaranteed to detect numanode migrations immediately and perform active migration of key memory, avoiding the lag of numa balance migration.

[0186] 2. For external use, a passive migration method is adopted, and the move_pages method is used instead of the migratepages command method. The overall migration mode is abandoned and a fine-grained memory migration mode is used, which saves more local memory.

[0187] 3. More specific segmentation for multi-threaded scenarios: In multi-threaded scenarios, some threads may run on node1, while others may run on node0. A complete migration would inevitably negatively impact the performance of some threads. Therefore, this application employs targeted strategies for handling stack data, .so files, and .bin files in both single-threaded and multi-threaded scenarios to avoid ineffective and harmful tuning.

[0188] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0189] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0190] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0191] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for migrating memory data, comprising: Obtain migration instructions for the target process; The target process contains at least one target thread; In response to the migration instruction, the following migration process is performed on the target thread: Obtain the memory data corresponding to the target thread; Determine whether the memory data is exclusively occupied by the target process; If the memory data is exclusively occupied by the target process, the memory data will be migrated to the target memory block. If the memory data is not exclusively occupied by the target process, the memory data is retained in the original memory block.

2. The method according to claim 1, wherein the memory data includes: The heap data corresponding to the target thread; Migrating the memory data to the target memory block includes: From the heap data, select the target data that meets the migration conditions; The target thread calls the memory page migration interface, which then migrates the target data to the target memory block. The target memory block is the memory block corresponding to the processing core where the target thread is located after migration, and the memory block corresponding to the processing core provides a memory area for the processing core to perform data calculations.

3. The method according to claim 2, wherein the migration conditions include: All data in the heap data that is exclusively accessed by the target thread; or, at least a portion of the data in the heap data that is exclusively accessed by the target thread and whose access frequency is greater than or equal to a threshold.

4. The method according to claim 1, wherein when there is only one target thread in the target process, the target memory block is the memory block corresponding to the processing core where the target thread is located after migration, and the memory block corresponding to the processing core provides a memory area for the processing core to perform data calculation; When there are multiple target threads in the target process, the target memory block includes: The memory block corresponding to the processing core where the target threads in the target process are migrated after exceeding the target number, and the target memory block is the memory block corresponding to the processing core where the target threads are migrated.

5. The method according to claim 1 or 4, wherein before migrating the memory data to the target memory block, the method further comprises: Using the memory block mapping information of the target process, determine whether the memory block where the memory data is located is the same as the target memory block; The memory block mapping information includes the mapping information between the memory data and the memory block in which it resides; If the memory block containing the memory data is the same as the target memory block, the memory data is retained in the original memory block; If the memory block containing the memory data is different from the target memory block, then the process of migrating the memory data to the target memory block is executed.

6. The method according to claim 1 or 4, determining whether the memory data is exclusively occupied by the target process, includes: Obtain the data type of the memory data; If the memory data is stack data, it is determined that the memory data is exclusively occupied by the target thread; If the memory data is heap data, it is determined that the memory data is exclusively occupied by the target process; If the memory data is a binary file, it is determined that the memory data is exclusively used by the target process. If the memory data is a shared object file, determine whether the memory data is exclusively occupied by the target process based on the occupancy identifier of the shared object file.

7. The method according to claim 1 or 4, wherein migrating the memory data to the target memory block comprises: According to the data address range of the memory data, the memory page migration interface is called using a pre-deployed migration process, and the memory page migration interface migrates the memory data to the target memory block.

8. The method according to claim 7, wherein the data address range of the memory data is obtained based on the address mapping information of the target process; in, The address mapping information includes the mapping information between the memory data and the start and end range of the virtual memory address it resides in.

9. A memory data migration device, comprising: The instruction acquisition unit is used to acquire migration instructions for the target process; The target process contains at least one target thread; A migration control unit, configured to perform the following migration process on the target thread in response to the migration instruction: Obtain the memory data corresponding to the target thread; Determine whether the memory data is exclusively occupied by the target process; If the memory data is exclusively occupied by the target process, the memory data will be migrated to the target memory block. If the memory data is not exclusively occupied by the target process, the memory data is retained in the original memory block.

10. An electronic device, comprising: Memory block; The controller is used to receive migration instructions for the target process; The target process contains at least one target thread; In response to the migration instruction, the following migration process is performed on the target thread: Obtain the memory data corresponding to the target thread; Determine whether the memory data is exclusively occupied by the target process; If the memory data is exclusively occupied by the target process, the memory data will be migrated to the target memory block. If the memory data is not exclusively occupied by the target process, the memory data is retained in the original memory block.

Images