Method and equipment for realizing vDSO code memory copy

Abstract

The invention relates to the technical field of virtual dynamic shared objects, and provides a method and device for achieving vDSO code memory replica, and the method comprises the steps that when a process is started, a vDSO code segment is mapped to an address space of the process; running the function code according to a preset running mechanism; and modifying the vDSO code segment by adopting the function code according to a preset rule, cancelling vDSO code segment mapping of the current process, and remapping a new vDSO code segment. According to the method and the equipment for realizing the vDSO code memory copy, the program performance can be obviously improved, vDSO copies of different levels can be flexibly realized, program and kernel codes do not need to be modified, the life cycle of the vDSO copies is efficiently managed, deployment and maintenance are simplified, the program or a kernel does not need to be modified, and a user can realize the vDSO code memory copy under the condition that an existing software architecture is not changed. And rapidly deploying and starting a vDSO memory copy function.

Description

Technical Field

[0001] This application relates to the technical field of virtual dynamic shared objects, and particularly to a method and device for implementing a memory copy of vDSO code. Background Art

[0002] vDSO (Virtual Dynamic Shared Object) is a kernel mechanism used to export a carefully selected set of kernel-space routines to user-space applications. Through vDSO, an application can call these kernel-space routines in a process without switching from user mode to kernel mode through the system call interface, thus avoiding the performance loss caused by mode switching. vDSO is linked and loaded using the standard Executable and Linkable Format (ELF), and a memory area is allocated in user space to expose kernel functions.

[0003] Overview of NUMA ArchitectureNon-Uniform Memory Access (NUMA) is a computer memory design for multiprocessing, where the memory access time depends on the location of the memory relative to the processor. Under the NUMA architecture, each processor node has local memory and can access the local memory or shared memory of other processors. However, accessing local memory is usually faster than accessing non-local memory. The I / O bus is usually associated with the NUMA architecture. For example, there are two NUMA nodes, each with local memory and a CPU. A process on NUMA0 can access the memory of NUMA1, but without a forced memory allocation policy configured, the operating system kernel usually allocates local memory for application processes to optimize memory access performance.

[0004] In practical applications, during the operating system startup phase, vDSO code fragments are loaded into physical memory. In a multi-NUMA environment, this physical memory is usually located in the NUMA0 node. When a process starts, the kernel is responsible for loading the process's data, code, and dynamic loader into memory and mapping the vDSO address range in the process's address space. The dynamic loader obtains the vDSO address through auxiliary variables, resolves function addresses in ELF format, and provides these functions for use by user programs, such as the gettimeofday() function. When multiple processes start on different NUMA nodes, although they can use the vDSO function, there is only one copy of the vDSO code in physical memory, and all processes share this part of the memory through read-only mapping. When a process runs on a NUMA node other than the one where the vDSO code is located, for example, process 3 runs on the NUMAx node while the vDSO code is located on the NUMA0 node, it will result in cross-NUMA node memory access. This cross-NUMA node access will increase the memory access latency, thereby reducing the performance of the application, and the performance reduction is positively correlated with the cross-NUMA memory access latency.

[0005] Therefore, how to solve the performance problems caused by cross-NUMA vDSO memory access has become a technical problem to be solved urgently. Summary of the Invention

[0006] In view of this, in order to overcome the deficiencies of the prior art, the present application aims to provide a method and device for implementing a memory copy of vDSO code.

[0007] According to the first aspect of the present application, a method for implementing a memory copy of vDSO code is provided, and the method includes: Step S101: When starting a process, map the vDSO code segment to the address space of the process; Step S102: Run the function code according to a preset operation mechanism; Step S103: Use the function code to modify the vDSO code segment according to a preset rule, cancel the mapping of the vDSO code segment of the current process, and remap a new vDSO code segment.

[0008] Optionally, in the method for implementing a memory copy of vDSO code of the present application, step S101 includes: Start the process through a system call. When the system starts, load the vDSO code fragment into physical memory; Before mapping the vDSO code segment to the address space of the process, load the executable program and dynamic loader of the started process into physical memory; After mapping the vDSO code segment to the address space of the process, transfer the control right to the dynamic loader corresponding to the process.

[0009] Optionally, in the method for implementing a memory copy of vDSO code of the present application, step S102 includes: Using the LD_PRELOAD function of the dynamic loader, load the function code into the process address space before loading the dynamic library on which the program depends, and run the function code before the execution of the main program function by using the constructor attribute in the loaded function code.

[0010] Optionally, in the method for implementing a memory copy of vDSO code of the present application, the preset rules in step S103 include: The vDSO memory dump rule of the process, which is used to determine whether it is necessary to dump the vDSO memory of the current process; The save and deletion rules of the vDSO dump file, which are used to manage the life cycle of the vDSO dump file; The naming rule of the vDSO dump file, which is used to determine the name of the vDSO dump file; The mapping rule of the vDSO dump file, which is used to map the vDSO dump file to the process address space; The naming rule for the vma of the new vDSO mapping, which is used to name the virtual memory area of the new vDSO mapping; The management rule for the vDSO memory copy information database, which is used to record and update the relevant information of the vDSO memory copy. The vDSO memory copy information database contains the following information: whether to dump the vDSO for the process, whether the vDSO has been dumped, the file name of the dumped vDSO, whether it is a process-level vDSO memory copy, whether it is a NUMA-level vDSO memory copy, the vma naming information of the vDSO memory mapping, the basic information of the process, and the corresponding relationship between the information.

[0011] Optionally, in the method for implementing the vDSO code memory copy of the present application, the vDSO memory dump rule of the process includes: If the current process is running on the NUMA node where the vDSO memory page of the operating system kernel is located, skip the dump process; If there is already a vDSO file dumped by other processes in the file system and the file has been mapped to the physical memory of the NUMA node where the current process is running, skip the dump process; If it is necessary to create a process-level vDSO copy, directly dump the vDSO memory into a file.

[0012] Optionally, in the method for implementing the vDSO code memory copy of the present application, the saving and deleting rules of the vDSO dump file include: When the process starts, save the vDSO memory to the file system according to the naming rule of the vDSO dump file; When the process exits, if a process-level vDSO memory copy is adopted, delete the corresponding vDSO dump file; If a NUMA-level vDSO memory copy is adopted, delete the dump file when there is no other process occupying the vDSO dump file.

[0013] Optionally, in the method for implementing the vDSO code memory copy of the present application, the naming rule of the vDSO dump file includes: If a NUMA-level vDSO copy is created, the vDSO dump file name should contain the NUMA node number information; If a process-level vDSO copy is created, the vDSO dump file name contains the process PID value or a random value.

[0014] Optionally, in the method for implementing the vDSO code memory copy of the present application, the mapping rule of the vDSO dump file includes: Use the mmap system call to map the dumped file to the memory; Or create an anonymous mapping and read data from a file into anonymous memory; When using an anonymous mapping, use a specific system call to set the virtual memory area name.

[0015] Optionally, in the method for implementing the vDSO code memory copy of the present application, the naming rule of the vma of the new vDSO mapping includes: If file mapping is adopted, there is no need to name the virtual memory area; If anonymous mapping is adopted, use the prctl system call to name the virtual memory area.

[0016] According to the second aspect of the present application, there is provided a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the method described in the first aspect of the present application is implemented.

[0017] A method for implementing the vDSO code memory copy of the present application can significantly improve the performance of a program in a multi-NUMA node environment, and has high flexibility and ease of use. The specific beneficial technical effects are as follows: 1. Significantly improve program performance. By introducing the concept of vDSO memory copy, processes running on different NUMA nodes can access the vDSO code in local memory, avoiding the high latency problem caused by cross-NUMA node access. This local access significantly reduces memory access latency, thereby greatly improving the performance of the program executing the vDSO code.

[0018] 2. Flexibly implement different levels of vDSO copies. By controlling preset rules, it is possible to easily implement vDSO memory copies at the process level and the NUMA system level. Users can flexibly configure the copy policy according to actual needs. They can either create independent vDSO copies in a single process or share copies on NUMA nodes, thereby achieving the best balance between performance and resource utilization.

[0019] 3. There is no need to modify the program and kernel code. Utilize the LD_PRELOAD function and constructor attributes of the dynamic loader to inject functional code into the process without modifying and recompiling the program code. At the same time, it is fully implemented in user space without any modification and recompilation of the kernel code. This design not only reduces the implementation complexity but also improves the generality and compatibility of the method, enabling it to be widely applied to various existing programs and operating system environments.

[0020] 4. Efficiently manage the life cycle of vDSO copies. By establishing a database of vDSO in-memory copy information to uniformly manage the creation, use, and destruction of copies, it can effectively avoid resource waste and potential conflicts, ensuring the efficient utilization of vDSO copies and the stable operation of the system. For example, when a process exits, the system automatically cleans up the corresponding vDSO copy to avoid unnecessary memory occupation.

[0021] 5. Simplify deployment and maintenance. Without modifying the program or kernel, users can quickly deploy and enable the vDSO in-memory copy function without changing the existing software architecture. This design not only reduces deployment costs but also simplifies the maintenance process, enabling system administrators to more easily manage and optimize system performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] To more clearly illustrate the technical solutions of the embodiments of the present application, the accompanying drawings required for use in the embodiments will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0023] Figure 1 FIG. is a flowchart of steps for a method of implementing a vDSO code in-memory copy according to an embodiment of the present application; Figure 2 FIG. is a schematic diagram of the principle of a method of implementing a vDSO code in-memory copy according to an embodiment of the present application; Figure 3 FIG. is an execution example diagram of a method of implementing a vDSO code in-memory copy according to an embodiment of the present application; Figure 4 FIG. is a schematic structural diagram of the device provided by the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0024] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0025] It should be noted that, without conflict, the following embodiments and the features in the embodiments can be combined with each other; and all other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present disclosure without creative efforts belong to the scope of protection of the present disclosure.

[0026] Note that the following description relates to various aspects of embodiments within the scope of the appended claims. It should be apparent that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art should understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects described herein can be used to implement an apparatus and / or practice a method. Additionally, this apparatus and / or method can be implemented using other structures and / or functionality in addition to one or more of the aspects described herein.

[0027] Figure 1 FIG. is a flowchart of steps of a method for implementing a memory copy of vDSO code according to an embodiment of the present application. The method for implementing a memory copy of vDSO code includes the following steps: Step S101: When starting a process, map the vDSO code segment to the address space of the process.

[0028] As an optional example, in this embodiment, the process is started through a system call. When the system starts, the vDSO code fragment is loaded into physical memory; before mapping the vDSO code segment to the address space of the process, the executable program and dynamic loader of the started process are loaded into physical memory; after mapping the vDSO code segment to the address space of the process, the control is transferred to the dynamic loader corresponding to the process.

[0029] Step S102: Run the functional code according to a preset operating mechanism.

[0030] As an optional example, in this embodiment, the LD_PRELOAD function of the dynamic loader is used. Before loading the dynamic libraries upon which the program depends, the functional code is loaded into the process address space. By using the constructor attribute in the loaded functional code, the functional code is run before the main program function is executed. In this embodiment, LD_PRELOAD is an environment variable in Linux and Unix-like systems, used to dynamically load specified shared libraries when a program runs. It allows custom shared libraries to be loaded before the program's default dynamic link libraries, thereby overriding or replacing the library functions used by default in the program.

[0031] Step S103: Modify the vDSO code segment according to a preset rule using the functional code, cancel the mapping of the vDSO code segment of the current process, and remap a new vDSO code segment.

[0032] As an optional example, the preset rules in this embodiment include: The vDSO memory dump rule of a process is used to determine whether to dump the vDSO memory of the current process. For example, in this embodiment, the vDSO memory dump rule of a process includes: if the current process is running on the NUMA node where the vDSO memory page of the operating system kernel is located, skip the dump process; if there is already a vDSO file dumped by another process in the file system and the file has been mapped to the physical memory of the NUMA node where the current process is running, skip the dump process; if a process-level vDSO copy needs to be created, directly dump the vDSO memory to a file.

[0033] The save and delete rules of the vDSO dump file are used to manage the life cycle of the vDSO dump file. For example, in this embodiment, the save and delete rules of the vDSO dump file include: when the process starts, save the vDSO memory to the file system according to the naming rule of the vDSO dump file; when the process exits, if a process-level vDSO memory copy is adopted, delete the corresponding vDSO dump file; if a NUMA-level vDSO memory copy is adopted, delete the dump file when no other process occupies the vDSO dump file.

[0034] The naming rule of the vDSO dump file is used to determine the name of the vDSO dump file. For example, in this embodiment, the naming rule of the vDSO dump file includes: if a NUMA-level vDSO copy is created, the vDSO dump file name should include the NUMA node number information; if a process-level vDSO copy is created, the vDSO dump file name contains the process PID value or a random value.

[0035] The mapping rule of the vDSO dump file is used to map the vDSO dump file to the process address space. For example, in this embodiment, the mapping rule of the vDSO dump file includes: using the mmap system call to map the dumped file to memory; or creating an anonymous mapping and reading data from the file into the anonymous memory; when using an anonymous mapping, using a specific system call to set the virtual memory area name. In this embodiment, the mmap system call is used to create a new memory area in the virtual memory space of the process or map a file, device memory, etc. to the address space of the process.

[0036] The vma naming rule for the new vDSO mapping is used to name the virtual memory areas of the new vDSO mapping. For example, in this embodiment, the vma naming rule for the new vDSO mapping includes: if file mapping is adopted, there is no need to name the virtual memory area; if anonymous mapping is adopted, the prctl system call is used to name the virtual memory area. In this embodiment, vma (Virtual Memory Area) is a data structure in the Linux kernel used to describe the memory areas of a process's virtual address space. Each vma represents a continuous virtual memory area in the process address space and contains relevant information about this area, such as the starting address, ending address, access permissions, mapped files, etc.

[0037] The management rule of the vDSO memory copy information database is used to record and update the relevant information of the vDSO memory copy. For example, in this embodiment, the vDSO memory copy information database contains the following information: whether to dump the vDSO for the process, whether the vDSO has been dumped, the file name of the dumped vDSO, whether it is a process-level vDSO memory copy, whether it is a NUMA-level vDSO memory copy, the vma naming information of the vDSO memory mapping, the basic process information, and the corresponding relationships between the various information.

[0038] The following is a detailed description of the method for implementing the vDSO code memory copy in this embodiment in a specific scenario.

[0039] Figure 2 As a principle example diagram of a method for implementing a vDSO code memory copy according to an embodiment of the present application, as Figure 2 shown, in this scenario, to solve the performance problem caused by cross-NUMA vDSO memory access, in this embodiment, by unmapping and file-sharing mapping, process 3 running on NUMAx uses the vDSO code of the local NUMA.

[0040] Specifically, in this scenario, the process is started through a system call. The kernel loads the executable program and the dynamic loader into physical memory, maps the code segment range required by vDSO, and then hands over the control to the dynamic loader. Modify the source code of the loader or use the running mechanism of the dynamic loader, such as LD_PRELOAD and constructor attributes, to run the code function. For example, in this embodiment, the LD_PRELOAD function of the dynamic loader is used to load the function code of this embodiment into the process address space before loading the dynamic libraries on which the program depends. This loading process is not limited to using LD_PRELOAD. In the function code of this embodiment, constructors such as the __attribute__((constructor)) attribute are used to implement the execution of the main function of the function of this embodiment before the main program main(). The __attribute__((destructor)) attribute is used to release the resources applied for by the function of this embodiment, delete files, etc. after the execution of the main program main() function ends. In addition, in this embodiment, the above functions can also be implemented by directly modifying the dynamic linker code.

[0041] In this embodiment, according to the preset rules, the current vDSO code is replaced, and the vDSO code segment of the current process is unmapped; according to the preset rules, a new vDSO code is remapped; after the dynamic loader completes the remaining work, the control is handed over to the main program.

[0042] For example, in this embodiment, the preset rules are used to specify the strategy for creating vDSO copies in the code function of the method of this application. This rule is used to specify the strategy for creating vDSO copies in the function of this proposal. Users can configure according to actual needs. In practical applications, the preset rules include: 1. The dump rule for the vDSO memory of the process: During the execution of the code function of this embodiment, the vDSO memory of the current program will be saved to a file. If the current process is running on the NUMA node where the vDSO memory page of the operating system kernel is located, the function of this proposal can be directly skipped without creating a vDSO copy; when there is already a vDSO file dumped by other processes in the file system and this vDSO file is mapped to the physical memory of the NUMA node where the current process is running, the dump process can be directly skipped. If you want to create a process-level vDSO copy, you can make no judgment and directly dump the vDSO to a file. Synchronously, update the "vDSO memory copy information database".

[0043] 2. Saving and Deletion Rules for vDSO Dump Files: When a process starts, the vDSO memory is saved to the file system according to the "Naming Rules for vDSO Dump Files". When a process exits, if a process-level vDSO memory copy is used, the vDSO dump file is deleted; if a NUMA-level vDSO memory copy is used, according to whether there is a process currently occupying this vDSO dump file, if not, this dump file is deleted. Synchronously, the "vDSO Memory Copy Information Database" is updated for the above operations.

[0044] 3. Naming Rules for vDSO Dump Files: If a NUMA-level vDSO memory copy is created, the vDSO dump file name needs to contain the NUMA node number information for indexing and naming during the "Dump of Process's vDSO Memory"; if a process-level vDSO memory copy is created, the vDSO dump file name can contain the process PID value or a random value.

[0045] 4. Mapping Rules for vDSO Dump Files: Use the mmap system call to map the dumped file to memory, or create an anonymous mapping and read data from the file into the anonymous memory. Optionally, when using an anonymous mapping, a specific system call can be used to set the vma name and update the "vDSO Memory Copy Information Database".

[0046] 5. vma Naming Rules for New vDSO Mapping: If file mapping is used, no naming is required. If anonymous mapping is used, the prctl system call can be used to name the vma and update the "vDSO Memory Copy Information Database".

[0047] 6. Management Rules for vDSO Memory Copy Information Database: The database contains: whether the process needs to dump vDSO, whether vDOS has been dumped, the vDSO dump file name, whether it is a process-level vDSO memory copy, whether it is a NUMA-level vDSO memory copy, the vma naming information of the vDSO memory mapping, the basic process information, and the corresponding relationships of the above contents.

[0048] Figure 3 An execution example diagram of a method for implementing a vDSO code memory copy according to an embodiment of the present application is as Figure 3 shown. In this scenario, assume that the vDSO code of the kernel is on the physical memory of NUMA0 node, and the method of the embodiment of the present application is executed according to the following steps: 1. Run process 3 on NUMAx, and the kernel maps the vDSO physical address on NUMA0 to the address space of process 3; 2. According to the running mechanism, taking LD_PRELOAD as an example, use the dynamic loader to execute the function of this proposal before the main() function; 3. Query whether there is already a vDSO copy dump file on NUMAx according to the preset rules. If not, dump the vDSO to the vDSO(x).elf file and unmap the current vDSO; 4. Map the dumped vDSO(x).elf file to the address space of process 3 according to the preset rules. This address exists in the memory of NUMAx; 5. Run process 4 on NUMAx. The kernel maps the physical address of the vDSO on NUMA0 to the address space of process 4; 6. Use the dynamic loader to execute the function of this proposal. This function determines that there is already a vDSO dump file vDSO(x).elf on NUMAx and skips the dump process; 7. Map the dumped vDSO(x).elf to the address space of process 4 according to the preset rules. This address exists in the memory of NUMAx, which is the same as in step 4; 8. Run process 5 on NUMAy. The kernel maps the physical address of the vDSO on NUMA0 to the address space of process 5; 9. Query whether there is already a vDSO copy dump file on NUMAy according to the preset rules. If not, dump the vDSO to the vDSO(y).elf file and unmap the current vDSO; 10. Map the dumped vDSO(y).elf to the address space of process 5 according to the preset rules. This address exists in the memory of NUMAy; According to the above steps, a NUMA-level copy of vDSO can be achieved. Similarly, modifying appropriate rules can also create a process-level vDSO copy.

[0049] According to an implementation method of the vDSO code memory copy in the embodiment of the present application, it can significantly improve the performance of the program in a multi-NUMA node environment and has high flexibility and ease of use. The specific beneficial technical effects are as follows: 1. Significantly improve program performance. By introducing the concept of vDSO memory copy, processes running on different NUMA nodes can access the vDSO code in local memory, avoiding the high latency problem caused by cross-NUMA node access. This local access significantly reduces the memory access latency, thereby greatly improving the performance of the program executing the vDSO code.

[0050] 2. Flexibly implement vDSO copies at different levels. By controlling preset rules, it is possible to easily implement vDSO memory copies at the process level and the NUMA system level. Users can flexibly configure the copy policy according to actual needs. They can either create independent vDSO copies in a single process or share copies on NUMA nodes, thus achieving the best balance between performance and resource utilization.

[0051] 3. Without modifying the program and kernel code, utilize the LD_PRELOAD function and constructor attributes of the dynamic loader to inject functional code into the process without modifying and recompiling the program code. At the same time, it is fully implemented in user space without any modification and recompilation of the kernel code. This design not only reduces the implementation complexity but also improves the generality and compatibility of the method, enabling it to be widely applied to various existing programs and operating system environments.

[0052] 4. Efficiently manage the vDSO copy lifecycle. By establishing a vDSO memory copy information database to uniformly manage the creation, use, and destruction of copies, it can effectively avoid resource waste and potential conflicts, ensuring the efficient utilization of vDSO copies and the stable operation of the system. For example, when a process exits, the system will automatically clean up the corresponding vDSO copy to avoid unnecessary memory occupation.

[0053] 5. Simplify deployment and maintenance. Without modifying the program or the kernel, users can quickly deploy and enable the vDSO memory copy function without changing the existing software architecture. This design not only reduces the deployment cost but also simplifies the maintenance process, enabling system administrators to more easily manage and optimize system performance.

[0054] As Figure 4 shown, this application also provides a device, including a processor 210, a communication interface 220, a memory 230 for storing processor-executable computer programs, and a communication bus 240. Among them, the processor 210, the communication interface 220, and the memory 230 complete mutual communication through the communication bus 240. The processor 210 realizes the above method for implementing vDSO code memory copies by running the executable computer program.

[0055] Among them, when the computer program in the memory 230 can be implemented in the form of software functional units and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in various embodiments of the present application. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program codes.

[0056] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected based on actual needs to achieve the purpose of the solution of this embodiment. A person of ordinary skill in the art can understand and implement it without creative efforts.

[0057] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on such an understanding, the above technical solution, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disks, optical discs, etc., and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods of various embodiments or certain parts of the embodiments.

[0058] As described above, this is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed in the present application should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for implementing vDSO code memory copy, characterized in that: The method comprises: Step S101: When a process is started, the vDSO code segment is mapped to the address space of the process; Step S102: running the function code according to a preset operation mechanism; Step S103: modify the vDSO code segment according to preset rules using the function code, cancel the vDSO code segment mapping of the current process, and remap a new vDSO code segment.

2. The method for implementing vDSO code memory copy according to claim 1, characterized in that: Step S101 includes: Start the process through a system call. When the system starts, the vDSO code fragment is loaded into the physical memory. Before mapping the vDSO code segment into the address space of the process, load the executable program and dynamic loader of the started process into physical memory; After mapping the vDSO code segment to the address space of the process, control is transferred to the dynamic loader corresponding to the process.

3. The method for implementing vDSO code memory copy according to claim 1, characterized in that: Step S102 includes: using the LD_PRELOAD function of the dynamic loader to load the function code into the process address space before loading the dynamic library that the program depends on, and running the function code before the main program function is executed by using the constructor attribute in the loaded function code.

4. The method for implementing vDSO code memory copy according to claim 1, characterized in that: The preset rules in step S103 include: vDSO memory dump rule of the process, used to determine whether to dump the vDSO memory of the current process; vDSO dump file preservation and deletion rules, used to manage the life cycle of vDSO dump files; vDSO dump file naming convention, used to determine the name of the vDSO dump file; vDSO dump file mapping rules, used to map vDSO dump files into process address space; The new vDSO mapping vma naming rules are used to name the new vDSO mapping virtual memory area; The management rules of the vDSO memory copy information database are used to record and update the relevant information of the vDSO memory copy. The vDSO memory copy information database contains the following information: whether the vDSO needs to be dumped for the process, whether the vDSO has been dumped, the dumped vDSO file name, whether it is a process-level vDSO memory copy, whether it is a NUMA-level vDSO memory copy, the vma naming information of the vDSO memory mapping, the process basic information, and the correspondence between each piece of information.

5. The method for implementing vDSO code memory copy according to claim 4, characterized in that: vDSO memory dump rules for the process, including: If the current process is running on the NUMA node where the vDSO memory page of the operating system kernel is located, skip the dump process; If a vDSO file dumped by another process already exists in the file system and the file has been mapped to the physical memory of the NUMA node where the current process is running, the dump process is skipped; If you need to create a process-level copy of the vDSO, dump the vDSO memory directly to a file.

6. The method for implementing vDSO code memory copy according to claim 4, characterized in that: vDSO dump file storage and deletion rules, including: When the process starts, the vDSO memory is saved to the file system according to the naming convention of the vDSO dump file; When the process exits, if the process-level vDSO memory copy is used, the corresponding vDSO dump file is deleted; If NUMA-level vDSO memory copy is used, the vDSO dump file is deleted when no other process occupies it.

7. The method for implementing vDSO code memory copy according to claim 4, characterized in that: The naming convention for vDSO dump files includes: If you create a NUMA-level vDSO copy, the vDSO dump file name should include the NUMA node number information; If you create a process-level vDSO copy, the vDSO dump file name contains the process PID value or a random value.

8. The method for implementing vDSO code memory copy according to claim 4, characterized in that: vDSO dump file mapping rules include: Use the mmap system call to map the dumped file into memory; Or create an anonymous mapping and read data from the file into anonymous memory; When anonymous mapping is used, the virtual memory region name is set using a specific system call.

9. The method for implementing vDSO code memory copy according to claim 4, characterized in that: New vDSO mapping vma naming rules, including: If file mapping is used, there is no need to name the virtual memory area; If anonymous mapping is used, the virtual memory area is named using the prctl system call.

10. A computer device, characterized in that: The computer device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the method according to any one of claims 1 to 9 when executing the program.

Images