Memory data migration method and device and electronic equipment

Abstract

The invention discloses a memory data migration method and device and electronic equipment. The method comprises the steps that a migration instruction for a target process is obtained; the target process comprises at least one target thread; in response to the migration instruction, executing the following migration process on the target thread: obtaining memory data corresponding to the target thread; judging whether the memory data is exclusively occupied by the target process or not; if the memory data is exclusively occupied by the target process, migrating the memory data to a target memory block; and if the memory data is not exclusively occupied by the target process, keeping the memory data in an original memory block.

Description

Technical Field

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

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

[0003] Currently, the migratepages method is usually used to migrate all memory data corresponding to the process to a certain memory block using the user-mode interface exposed by the kernel.

[0004] However, this overall memory migration approach may increase the system burden. Summary of the invention

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

[0006] A method for migrating memory data, comprising:

[0007] Obtaining a migration instruction for a target process; the target process includes at least one target thread;

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

[0009] Obtain 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, migrating the memory data to a 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] Filtering target data that meets migration conditions from the pile of data;

[0016] Using the target thread to call a memory page migration interface, the memory page migration interface migrates the target data to a target memory block;

[0017] The target memory block is a 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.

[0018] In the above method, preferably, the migration condition includes: all data in the heap data that is exclusively occupied by the target thread; or at least part of the data in the heap data that is exclusively occupied by the target thread and has an access frequency greater than or equal to a threshold.

[0019] In the above method, preferably, when there is only one target thread in the target process, the target memory block is a 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;

[0020] In the case where there are multiple target threads in the target process, the target memory block includes: a memory block corresponding to a processing core where target threads exceeding the target number in the target process are located after migration, and a memory block corresponding to a processing core where the target threads are located after migration.

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

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

[0023] If the memory block where the memory data is located is the same as the target memory block, retaining the memory data in the original memory block;

[0024] If the memory block where the memory data is located is different from the target memory block, the memory data is migrated to the target memory block.

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

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

[0027] In a case where the memory data is stack data, determining that the memory data is exclusively occupied by the target thread;

[0028] In a case where the memory data is heap data, determining that the memory data is exclusively occupied by the target process;

[0029] In the case where the memory data is a binary file, determining that the memory data is exclusively occupied by the target process;

[0030] In the case that the memory data is a shared object file, it is determined whether the memory data is exclusively occupied by the target process according to an occupation flag of the shared object file.

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

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

[0033] In the above method, preferably, the data address range of the memory data is obtained according to 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 ranges of the virtual memory addresses where the memory data is located.

[0035] A memory data migration device, comprising:

[0036] An instruction acquisition unit, configured to obtain a migration instruction for a target process; the target process includes at least one target thread;

[0037] A migration control unit is used to execute the following migration process on the target thread in response to the migration instruction:

[0038] Obtain 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, migrating the memory data to a 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 blocks;

[0044] The controller is configured to obtain 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 for the target thread:

[0045] Obtain 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, migrating the memory data to a 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 means of the above technical solution, in a memory data migration method, device and electronic device provided by the present 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 determine whether it is exclusively occupied by the target process, and migrate the exclusive memory data to the target memory block, and retain the non-exclusive memory data in the original memory block. It can be seen that in the present application, the exclusive memory data is migrated in units of each thread in the process, rather than migrating the entire memory data of the process to one memory block, so that the burden on the system can be reduced by breaking the whole into parts, thereby improving the efficiency of memory data migration. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

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

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

[0053] Figure 3 Another flow chart of a method for migrating memory data provided in an embodiment of the present application;

[0054] Figure 4 A partial flow chart of a method for migrating memory data provided in an embodiment of the present application;

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

[0056] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0057] Figure 7 This is a flow chart of actively migrating heap area data by each thread in an embodiment of the present application;

[0058] Figure 8 This is a flowchart of passively migrating so files, bin files and stack data in a single-threaded manner through a third-party process in an embodiment of the present application;

[0059] Fig. 9 This is a flowchart of passively migrating so files, bin files and stack data through a third-party process in a multi-threaded environment in an embodiment of the present application. DETAILED DESCRIPTION

[0060] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0061] refer to Figure 1 As shown, it is a flowchart of a memory data migration method provided by an embodiment of the present application, and the method can be applied to an electronic device having a processing core and a memory block for process operation. Figure 2 As shown in , multiple electronic devices are interconnected, and the memory blocks provided by each electronic device form a memory pool, so that the memory pool contains multiple memory blocks, which are provided by multiple interconnected electronic devices. Among them. An electronic device can provide one or more memory blocks, and in addition, the electronic device also provides a processing core corresponding to the memory block. Among them, the storage performance of the memory blocks provided by different electronic devices is the same or different, and the processing performance of the processing cores provided by different electronic devices is the same or different. In a specific implementation, the memory pool can be constructed based on multiple electronic devices by computing a fast link CXL (Compute Express Link), and further, the processing cores and memory blocks provided by these multiple electronic devices can use a non-uniform memory access NUMA (Non Uniform Memory Access) architecture to implement memory access. Based on this, the memory data migration method in this embodiment can be applicable to the memory data migration scenario between any two memory blocks in the memory pool, including memory migration between memory blocks in the same electronic device, and also including 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 a migration instruction for a target process.

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

[0065] It should be noted that the migration instruction is generated when a thread in the target process undergoes core migration. The migration instruction of the target process is used to instruct each target thread in the target process to migrate from the current core to the target core. The processing cores of different target threads after migration can be the same or different. The target thread here can be understood as the thread where the core migration occurs. For example, the target process has 5 target threads: thread 1 to thread 5. When migrating the target process, thread 1, thread 2 and thread 3 are migrated to processing core a, thread 4 is migrated to processing core b, and thread 5 is migrated to processing core c. Processing core a and processing core c are on the same electronic device, and processing core b is on another electronic device. The processing core where each target thread is located before and after migration can be on the same electronic device or on different electronic devices.

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

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

[0068] In this embodiment, memory data migration is performed with threads as migration units, thereby achieving fine-grained memory data migration. Specifically, in this embodiment, for each target thread, the migration process described in steps 121 to 124 is executed respectively. Specifically, as follows:

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

[0070] Among them, the memory data may include: heap data, stack data, shared object files, binary files and other memory data corresponding to the target thread. Heap data refers to: data stored in the heap memory (heap space) allocated to each target thread in the target process. Stack data refers to: data stored in the stack memory (stack space) allocated to each target thread in the target process. Binary files refer to files in bin format, which are used to store data, program code and other content. Shared object files refer to files in so format, which can also be called shared object files or shared library files.

[0071] It should be noted that the target thread in this embodiment refers to the thread in the target process that needs to perform memory data migration, that is, the target thread is the thread in the target process where the processing core migration occurs. In a specific implementation, the information of the processing core to which the thread migrates can be obtained by calling the syscall interface of the kernel. 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 of the processing core where the thread is currently located, and the information is compared with the information of the processing core where the thread is previously recorded. If the comparison is inconsistent, it can be determined that the thread has undergone processing core migration, and the thread is determined 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, execute step 123; if the memory data is not exclusively occupied by the target process, execute step 124.

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

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

[0075] The original memory block is the memory block where the memory data is originally located, and the target memory block is another memory block different from the original memory block.

[0076] Based on this, if the memory data is exclusively occupied by the target process, it means that the migration of the memory data will not affect the normal operation of other processes. At this time, 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 occupying the memory data at the same time. At this time, the memory data needs to be kept in the original memory block. In this way, memory data can be migrated in threads, and the normal operation of other processes can be ensured not to be affected.

[0077] By means of the above technical solution, in a memory data migration method provided by an embodiment of the present application, 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, and for the exclusive memory data, it is migrated to the target memory block, and for the non-exclusive memory data, it is retained in the original memory block. It can be seen that in this embodiment, the exclusive memory data is migrated in units of each thread in the process, rather than migrating the entire memory data of the process to one memory block, so that the burden on the system can be reduced by breaking the whole into parts, thereby improving the efficiency of memory data migration.

[0078] In one implementation, the memory data includes: heap data corresponding to the target thread. The heap data is data occupied by the target thread and may also be occupied by other threads, that is, the data in the thread's own divided heap memory is visible to other threads in the process and can be shared with other threads, but 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, in step 123, when migrating the memory data to the target memory block, it can be implemented in the following ways:

[0080] First, filter out the target data that meets the migration conditions from the heap data;

[0081] Then, the target thread is used to call the memory page migration interface, and the memory page migration interface migrates the target data to the target memory block.

[0082] The target memory block is a 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.

[0083] It should be noted that the memory block corresponding to the processing core refers to the proximal memory block of the processing core at the hardware level. The proximal memory block of a processing core can be regarded as a remote memory block for other processing cores, and for a processing core, the proximal memory blocks of other processing cores can be regarded as remote memory blocks. The processing core has the fastest access speed when accessing data in its proximal memory block.

[0084] Based on this, in this embodiment, for heap data, the target thread itself 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. In this way, there is no need to rely on the migration process but the memory data migration can be achieved by the target thread itself, thereby reducing the proximal (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 specific implementation, the memory page migration interface may be a movepage interface in an operating system, which can migrate memory data.

[0086] Based on the above implementation, the migration condition may include: all the data of the heap data, all the data in the heap data that is exclusively occupied by the target thread, or at least part of the data in the heap data that is exclusively occupied by the target thread and has an access frequency greater than or equal to a threshold. The threshold here can be set according to demand. The access frequency of the memory data can be recorded in the field corresponding to the memory data through data statistics. Based on this, in this embodiment, the access frequency of the memory data can be read from the field, and then the memory data that is exclusively occupied by the target thread and has an access frequency greater than or equal to the threshold is screened out, that is, the target data that meets the migration condition.

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

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

[0089] For another example, in this embodiment, the target thread itself can migrate the hot data in the part of the heap data exclusively occupied by the target thread to the memory block corresponding to the processing core where the target thread is located after migration by calling the movepage interface. The hot data in the heap data refers to: data in the heap data whose access frequency is greater than or equal to a threshold, that is, data frequently accessed by users.

[0090] It can be seen that in this embodiment, the exclusive memory data is migrated on a per-thread basis in the process, rather than migrating the entire memory data of the process to one memory block. This method of breaking the whole into parts can reduce the burden on the system. Moreover, for heap data, in this embodiment, the data that meets the migration conditions is migrated to the proximal memory block, which can save proximal memory space, improve the efficiency of memory data migration, and optimize program running 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 proximal memory block of the processing core.

[0092] For example, the target process has one target thread: thread 1. Thread 1 is migrated to processing core c. At this time, the target memory block is the memory block corresponding to processing core c, that is, the proximal 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 blocks include: memory blocks corresponding to the processing cores where the target threads exceeding the target number in the target process are located after migration, and the target memory blocks are memory blocks corresponding to the processing cores where the target threads are located after migration.

[0094] In a specific implementation, the target memory blocks to which memory data of different data types are migrated may be different. For example, for memory data of a first data type, such as a binary file or a shared object file, 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 to which target threads exceeding the target number in the target process are migrated; for memory data of a 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 to which the target thread is migrated.

[0095] The target number here may be: a value corresponding to the maximum number of threads running on the processing core where each thread in the target process is located after migration. For example, the number obtained by subtracting 1 from the maximum value is set as the target number.

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

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

[0098] Step 125: 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. If the memory block where the memory data is located is the same as the target memory block, execute step 124; if the memory block where the memory data is located is different from the target memory block, execute 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 at least provides the memory mapping information allocated to each thread in the process. The numa_maps file can be in the / proc / pid / numa_maps directory, and pid is the process identifier of the target process. By viewing the numa_maps file, the memory allocation object and address of the task can be determined. Based on this, in this embodiment, after reading the numa_maps file, the memory block corresponding to the memory data of each target thread in the target process can be found in the numa_maps file. Thus, in this embodiment, the memory block corresponding to the memory data of the target thread can be compared with the target memory block. If the comparison is consistent, then there is no need to migrate the memory data, that is, to retain the memory data in the original memory block. At this time, the original memory block is the memory block corresponding to the processing core where the target thread is located after migration, or the original memory block is the memory block corresponding to the processing core where the target thread is located after migration exceeding the target number; if the comparison is inconsistent, then the memory data is migrated to the target memory block, and the target memory block at this time is not a memory block with the original content block.

[0100] It can be seen that in this embodiment, when the target process contains multiple target threads, the memory block mapping information of the target process is first used to determine whether the original memory block where the memory data is located is the memory block corresponding to the processing core where the target threads exceeding the target number are migrated. This can avoid migrating the memory data in the same memory block, thereby saving the memory resources occupied by the migration and improving the migration efficiency.

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

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

[0103] The memory data may 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, execute step 403; if the memory data is heap data, execute step 404; if the memory data is a binary file, execute step 404; if the memory data is a shared object file, execute step 405.

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

[0106] Among them, the data type of the stack data is a data type exclusively occupied by the thread to which it belongs. If it is exclusively occupied by the thread, then it can be determined that it is exclusively occupied by the process to which the thread belongs. The data type of the heap data is a data type exclusively occupied by the process. Therefore, for the memory data of the stack data, it can be determined that the memory data of the data type of the stack data corresponding to the target thread is exclusively occupied by the target process. Based on this, in this embodiment, the memory data of the data type of these stack data are migrated to the target memory block, such as the memory block corresponding to the processing core where the target thread is located after migration, that is, the proximal memory block.

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

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

[0109] Step 405: Determine whether the memory data is exclusively occupied by the target process according to the occupation flag of the shared object file.

[0110] Among them, the shared object file may be occupied by one or more processes. The shared object file corresponds to an occupation flag, which can be represented by a numerical value, which represents the number of processes occupying the shared object file. For example, if the occupation flag of the shared object file is 1, it means that the shared object file is only occupied by the process to which the thread belongs; if the occupation flag of the shared object file is greater than 1, it means that the shared object file is occupied by another process in addition to the process to which the thread belongs. Based on this, in this embodiment, it can be determined whether the occupation flag of the shared object file is 1 to determine whether the memory data is occupied by the target process. Based on this, in this embodiment, when the occupation flag of the shared object file is 1, the memory data of these shared object files are migrated to the target memory block. If the occupation flag of the shared object file 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] It can be seen that in this embodiment, it is possible to determine whether memory data of different data types are exclusively occupied by the target process, thereby migrating memory data of different data types separately to achieve fine-grained data migration in the data dimension, thereby reducing migration resource consumption to improve migration efficiency while ensuring the normal operation of other processes and improving the reliability of process operation.

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

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

[0114] The migration process is a process different from the target process, and the migration process is a pre-deployed process mainly used to migrate memory data. Based on this, in this embodiment, the migration of memory data can be performed through the specially deployed migration process, thereby accelerating the migration rate of memory data and improving migration efficiency.

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

[0116] Based on the above implementation scheme, the data address range of the memory data can be obtained according to the address mapping information of the target process, and the address mapping information can include mapping information between the memory data and the start and end range of the virtual memory address where the memory data is located.

[0117] For example, the address mapping information can be obtained from the maps file, which is a file that displays the memory mapping information corresponding to each thread in the process. The maps file is located in the / proc / pid / maps directory, where pid represents the process ID (identification) of the process. The memory mapping information (address mapping information) in the maps file specifically includes: the mapping relationship between the memory data corresponding to each thread in the process and the start and end ranges composed of the start and end positions of the virtual memory addresses where these memory data are located. Based on this, in this embodiment, the start and end ranges of the virtual memory addresses where the memory data is located, that is, the data address range of the memory data, can be obtained from the address mapping information, and then the migration process calls the memory migration interface such as the movepage interface according to the data address range, and the memory migration interface reads memory data such as binary files, shared object files, stack data, heap data, etc. according to the data address range and migrates the read memory data to the target memory block.

[0118] refer to Figure 5 , is a schematic diagram of the structure of a memory data migration device provided in an embodiment of the present application, the device can be configured in an electronic device having a processing core and a memory block for process operation, such as Figure 2 The electronic device shown in the figure. 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 obtain a migration instruction for a target process; the target process includes at least one target thread;

[0121] The migration control unit 502 is used to execute the following migration process on the target thread in response to the migration instruction:

[0122] Obtain 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, migrating the memory data to a 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] It can be seen from the above technical solution that in a memory data migration device provided by an embodiment of the present application, 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, and for the exclusive memory data, it is migrated to the target memory block, and for the non-exclusive memory data, it is retained in the original memory block. It can be seen that in this embodiment, the migration of exclusive memory data is performed on a per-thread basis in the process, rather than migrating the entire memory data of the process to one memory block, so that the burden on the system can be reduced by breaking the whole into parts, thereby improving the efficiency of memory data migration.

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

[0128] Among them, when migrating the memory data to the target memory block, the migration control unit 502 is specifically used to: filter out the target data that meets the migration conditions from the heap data; use the target thread to call the memory page migration interface, and the memory page migration interface migrates 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 calculation.

[0129] For example, the migration condition includes: all data in the heap data that is exclusively occupied by the target thread; or at least part of the data in the heap data that is exclusively occupied by the target thread and has an access frequency 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 the target threads exceeding the target number are located after migration in the target process.

[0131] Based on this, when there are multiple target threads in the target process, the migration control unit 502 is also used 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 contains 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 the migration control unit 502 determines whether the memory data is exclusively occupied by the target process, it is specifically used to: obtain the data type of the memory data; when the memory data is stack data, determine that the memory data is exclusively occupied by the target thread; when the memory data is heap data, determine that the memory data is exclusively occupied by the target process; when the memory data is a binary file, determine that the memory data is exclusively occupied by the target process; when the memory data is a shared object file, determine whether the memory data is exclusively occupied by the target process based on the occupancy flag 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 is specifically used to: call the memory page migration interface according to the data address range of the memory data using the pre-deployed migration process, 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 according to the address mapping information of the target process; the address mapping information includes mapping information between the memory data and the start and end ranges of the virtual memory addresses where the memory data is located.

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

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

[0137] Memory block 601, implemented by a memory, for storing memory data;

[0138] The controller 602 is configured to obtain 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 for the target thread:

[0139] Obtain 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, migrating the memory data to a 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 further include a processing core 603, which is used to run a target thread. The processing core 603 uses a memory area provided by the memory block 601 to perform data calculations to run the corresponding target thread.

[0144] It can be seen from the above technical solution that in an electronic device provided by an embodiment of the present application, 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, and for the exclusive memory data, it is migrated to the target memory block, and for the non-exclusive memory data, it is retained in the original memory block. It can be seen that in this embodiment, the migration of exclusive memory data is performed on each thread in the process as a unit, rather than migrating the entire memory data of the process to one memory block, so that the burden on the system can be reduced by breaking the whole into parts, thereby improving the efficiency of memory data migration.

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

[0146] In a system architecture built on NUMA and CXL, different processing cores, such as the central processing unit (CPU), have different access rates when accessing different memory blocks, such as memory data in a numanode. This leads to stratified memory access latency. Therefore, optimizing software performance without increasing hardware costs becomes a key issue.

[0147] At present, the migratepages interface is often used to migrate all the memory data of a process to a numanode. However, this migration solution can only migrate the memory data of the process as a whole. When the memory of a numanode is tight, the overall memory data migration will increase the system burden and cause waste of local memory.

[0148] In view of the above problems, this application proposes an adaptive performance tuning method that combines internal and external factors. The internal and external factors here can be understood as an active and passive method to quickly migrate memory on demand. Among them:

[0149] Internal: refers to the memory data migration of the thread (code) itself. For example, internal is the active migration initiated by the thread, which is triggered and processed by the thread according to logic. There are the following key points:

[0150] (1) User-defined important hot memory: Customize the global hot memory list pagelist according to the running logic of the own code execution.

[0151] (2) Thread operation monitoring: After obtaining the CPU information, numanode information, and process pid information of the processing core where the thread is located, the function is encapsulated and recorded. When the thread is running, the CPU and numanode information are compared. If the numanode is different, the thread actively triggers the migration of key memory in the pagelist.

[0152] (3) Thread memory migration: To avoid the impact of memory migration on other processes or the repeated migration of shared memory between processes, in this case, when migrating the memory of each thread, use the move_page function with the MPOL_MF_MOVE parameter to migrate only the exclusive memory of the thread, such as stack data and exclusive heap data, and the exclusive memory data of the process, such as bin files and so files.

[0153] It should be noted that the migration is mainly done internally on the heap area (i.e., heap data). The heap areas of different threads can actively migrate the exclusive data in the heap areas they use to the corresponding numanode as the threads are scheduled by their CPUs.

[0154] External: refers to the process of assisting memory migration tuning from a third-party perspective. The third-party process (i.e. the migration process mentioned above) monitors and processes the target process. In this case, it is necessary to distinguish whether the tuning process is single-threaded or multi-threaded. Externally, it is passive intervention, but it helps the rapid convergence of memory migration. The following describes the single-threaded and multi-threaded situations respectively:

[0155] 1. In the case of a single thread, the external single thread will obtain the executed numanode node, and the memory data has the following data types:

[0156] (1) bin file (binary file): The bin file may be shared among threads within a process, but it is definitely owned exclusively 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, the so files whose corresponding field mapmax is 1 (that is, the so files exclusively used by the current process) are completely migrated, and the so files whose mapmax is other values ​​are not migrated to avoid affecting other task processes.

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

[0159] 2. In the case of multi-threading, memory data has the following data types:

[0160] (1) bin file: The migration principle is: migrate to the numanode on which most of the multithreading runs. This numanode is the memory block numanode corresponding to the processing core where the target threads exceeding the target number are migrated.

[0161] (2) so file: Migrate the file with mapmax value 1 to the numanode corresponding to the processing core where most threads are migrated, while avoiding affecting other task processes.

[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, that is, the proximal numanode.

[0163] It should be noted that:

[0164] A. For the exclusive check of the so file, since multiple threads of a process share the so file mapping, namely mapmax, it is only necessary to check the mapping mapmax of the process or one of its threads.

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

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

[0167] like Figure 7 As shown in , it is a flowchart of each thread actively migrating heap data internally. In this embodiment, the following process is implemented through the function interface file of so or .a:

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

[0169] Then, determine whether the thread has a core migration, that is, whether the heap data needs to be migrated to numanode;

[0170] If migration is required, the thread calls the move_page interface to migrate the hot data 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 migration.

[0171] like Figure 8 As shown in the figure, it is a flowchart of passively migrating so files, bin files and stack data through a third-party process in a single thread, as follows:

[0172] First, get the CPU where the thread is located after migration, that is, the target memory block mentioned above;

[0173] Then, by reading numa_maps, check the numanode where the bin file is located; determine whether the bin file is in the remote node. Here, the bin file in the remote node means that the numanode where the bin file is located is inconsistent with the numanode corresponding to the CPU where the thread is located after migration; if the bin file is not in the remote node, that is, the numanode corresponding to the CPU where the bin file is located after the thread migration (the near-end numanode), then there is no need to migrate the bin file; if the bin file is in the remote node, then read maps to obtain the data address range of the bin file, and then call the move_page interface according to the data address range to migrate the bin file corresponding to the thread to the numanode corresponding to the CPU where the thread is located after migration;

[0174] After that, start the so file check and check each so file in the following way:

[0175] By reading numa_maps, check the numanode where the so file is located, and determine whether the so file is in a remote node. Here, the so file in the remote node means that the numanode where the so file is located is inconsistent with the numanode corresponding to the CPU where the thread is located after migration. If the so file is not in the remote node, that is, the numanode corresponding to the CPU where the so file is located after the thread migration (near-end numanode), then there is no need to migrate the so file; if the so file is in the remote node, then determine whether mapmax is 1. If it is not 1, it means that it is not exclusively occupied by the process, and the so file does not need to be migrated, and then continue to check other so files; if mapmax is 1, obtain the data address range of the so file by reading maps, and then call the move_page interface according to the data address range to migrate the so file corresponding to the thread to the numanode corresponding to the CPU where the thread is located after migration, until all so files are checked;

[0176] Finally, start the stack data check: by reading numa_maps, check the numanode where the stack data is located; determine whether the stack data is in the remote node. The stack data in the remote node here means that the numanode where the stack data is located is inconsistent with the numanode corresponding to the CPU where the thread is located after migration; if the stack data is not in the remote node, that is, the stack data is in the numanode corresponding to the CPU where the thread is located after migration (near-end numanode), then there is no need to migrate the stack data; if the stack data is in the remote node, then obtain the data address range of the stack data by reading maps, and then call the move_page interface according to the data address range to migrate the stack data corresponding to the thread to the numanode corresponding to the CPU where the thread is located after migration.

[0177] like Fig. 9 As shown in the figure, it is a flowchart of passively migrating so files, bin files and stack data through a third-party process in a multi-threaded situation, as follows:

[0178] Get the CPU where most threads are migrated, which is the target memory block mentioned above; perform the following checks on each thread:

[0179] First, by reading numa_maps, check the numanode where the bin file is located; determine whether the bin file is in the node where a few threads are located after migration or in the node where most threads are located after migration (that is, the numanode corresponding to the CPU where most threads are located after migration); if the bin file is not in the node where a few threads are located after migration, that is, it is in the node where most threads are located after migration, then there is no need to migrate the bin file; if the bin file is in the node where a few threads are located after migration, then obtain the data address range of the bin file by reading maps, and then call the move_page interface according to the data address range to migrate the bin file corresponding to the thread to the numanode corresponding to the CPU where the thread is located after migration;

[0180] After that, start the so file check and check each so file in the following way:

[0181] By reading numa_maps, check the numanode where the so file is located, and determine whether the so file is in the node where a few threads are migrated or in the node where most threads are migrated (that is, the numanode corresponding to the CPU where most threads are migrated). If the so file is not in the node where a few threads are migrated, that is, it is in the node where most threads are migrated, then there is no need to migrate the so file; if the so file is in the node where a few threads are migrated, then determine whether mapmax is 1. If it is not 1, it indicates that it is not exclusively occupied by the process, and the so file does not need to be migrated, and then continue to check other so files; if mapmax is 1, obtain the data address range of the so file by reading maps, and then call the move_page interface according to the data address range to migrate the so file corresponding to the thread to the numanode corresponding to the CPU where the thread is migrated, until all so files are checked;

[0182] Finally, start checking the stack data and perform the following checks on each thread:

[0183] By reading numa_maps, check the numanode where the stack data is located; determine whether the stack data is in a remote node. The stack data in a remote node here means that the numanode where the stack data is located is inconsistent with the numanode corresponding to the CPU where the thread is located after migration; if the stack data is not in the remote node, then there is no need to migrate the stack data, and continue to check the next thread; if the stack data is in the remote node, then obtain the data address range of the stack data by reading maps, and then call the move_page interface according to the data address range to migrate the stack data corresponding to the thread in memory, that is, migrate it to the numanode corresponding to the CPU where the thread is located after migration, until all threads have been checked.

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

[0185] 1. Using active migration instead of numa balance mode internally can ensure that the process is aware of numanode migration at the first time and actively migrates key memory to avoid the lag of numa balance migration.

[0186] 2. Passive migration is adopted for external use, 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 to save more local memory.

[0187] 3. There is a clearer subdivision for multi-threaded scenarios, because in multi-threaded scenarios, some threads may run on node1, and some threads may run on node0. The overall migration will inevitably have an adverse impact on the performance of some threads. Therefore, this application has carried out targeted strategic processing on stack data, so files and bin files in single-threaded and multi-threaded situations to avoid invalid tuning and harmful tuning.

[0188] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0189] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0190] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a 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 implement or use the present application. Various modifications to these embodiments will be 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 the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to 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 includes at least one target thread; In response to the migration instruction, the following migration process is performed on the target thread: Obtain 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, migrating the memory data to a 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 comprises: Heap data corresponding to the target thread; Migrating the memory data to the target memory block includes: Filtering target data that meets migration conditions from the pile of data; Using the target thread to call a memory page migration interface, the memory page migration interface migrates the target data to a target memory block; The target memory block is a 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.

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

4. According to the method of claim 1, when there is only one target thread in the target process, the target memory block is a 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; In the case where there are multiple target threads in the target process, the target memory block includes: The target memory block is the memory block corresponding to the processing core where the target threads exceeding the target number in the target process are located after migration, and the target memory block is the memory block corresponding to the processing core where the target threads are located after migration.

5. The method according to claim 1 or 4, before migrating the memory data to the target memory block, the method further comprises: Using the memory block mapping information of the target process, determining whether the memory block where the memory data is located is the same as the target memory block; The memory block mapping information includes mapping information between the memory data and the memory block where the memory data is located; If the memory block where the memory data is located is the same as the target memory block, retaining 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, the memory data is migrated to the target memory block.

6. The method according to claim 1 or 4, determining whether the memory data is exclusively occupied by the target process comprises: Obtaining the data type of the memory data; In a case where the memory data is stack data, determining that the memory data is exclusively occupied by the target thread; In a case where the memory data is heap data, determining that the memory data is exclusively occupied by the target process; In the case where the memory data is a binary file, determining that the memory data is exclusively occupied by the target process; In the case that the memory data is a shared object file, it is determined whether the memory data is exclusively occupied by the target process according to an occupation flag of the shared object file.

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

8. The method according to claim 7, wherein the data address range of the memory data is obtained according to the address mapping information of the target process; in, The address mapping information includes mapping information between the memory data and the start and end ranges of the virtual memory addresses where the memory data is located.

9. A memory data migration device, comprising: An instruction acquisition unit, used for acquiring a migration instruction for a target process; The target process includes at least one target thread; A migration control unit is used to execute the following migration process on the target thread in response to the migration instruction: Obtain 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, migrating the memory data to a 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 blocks; A controller, used to obtain migration instructions for a target process; The target process includes at least one target thread; In response to the migration instruction, the following migration process is performed on the target thread: Obtain 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, migrating the memory data to a 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