Memory pre-loading processing method, and device and storage medium

Abstract

Provided in the present application are a memory pre-loading processing method, and a device and a storage medium. The method comprises: a virtual machine manager collecting a plurality of pieces of historical page fault information that are generated by a target application program in a client; on the basis of a plurality of client virtual addresses that are included in the plurality of pieces of historical page fault information, determining a target client virtual address to be accessed when a page fault occurs in the target application program next time; on the basis of the target client virtual address and a storage address of a target client system page table corresponding to the target application program, determining a target host machine virtual address corresponding to the target client virtual address; and controlling a host machine operating system to allocate a target host machine physical address corresponding to the target host machine virtual address, and loading data, which corresponds to the target host machine virtual address, into the target host machine physical address. By means of loading, into a memory in advance, data corresponding to a target client virtual address in which a page fault may occur in the future, an access delay duration caused by the page fault is shortened.

Description

Memory preloading processing method, device and storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on July 27, 2023, with application number 202310936118.4 and application name “Memory Preloading Processing Method, Device and Storage Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present invention relates to the field of cloud computing technology, and in particular to a memory preloading processing method, device and storage medium. Background Art

[0003] In a non-virtualized scenario, applications access memory (i.e., main memory, the physical storage medium) through virtual addresses (VAs). In response to a memory access request triggered by an application for a specific VA, the CPU's memory management unit (MMU) maps the VA to the physical address (PA) based on a page table that stores the mapping relationship between virtual addresses and physical addresses (PAs), and then uses the mapped PA to access memory. In practice, different applications in an electronic device have their own corresponding page tables, but these applications share memory. For example, a memory actually has 4GB of physical address space, but each application can have 4GB of virtual address space. Each application believes that it can use the 4GB address space of the memory.

[0004] In practice, when an application issues an access request for a specific VA and the CPU fails to successfully locate the corresponding PA based on the corresponding page table, it means that the data corresponding to the VA has likely not yet been loaded into memory, that is, the PA corresponding to the VA has not yet been allocated. This will result in a page fault. After a page fault occurs, the corresponding data must be read from disk into memory, and the MMU must then establish a mapping relationship between the VA and the corresponding PA. This allows the application to execute the access request normally based on this mapping relationship. Loading data and establishing the mapping relationship between addresses is time-consuming, and the application must wait for a long time before it can resume normal execution.

[0005] Summary of the Invention

[0006] The embodiments of the present invention provide a memory preloading processing method, device and storage medium, which are used to reduce the processing time of an application program when a page fault exception occurs.

[0007] In a first aspect, an embodiment of the present invention provides a memory preloading processing method, which is applied to a virtual machine manager, and the method includes:

[0008] At a current prediction moment, collecting a plurality of historical page fault exception information generated when a target application in a client accesses a memory, the plurality of historical page fault exception information including a plurality of client virtual addresses corresponding to the target application;

[0009] determining, based on the plurality of client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application;

[0010] Determining a target host machine virtual address corresponding to the target client virtual address on the host machine side according to the target client machine virtual address and a storage address of a target client machine system page table corresponding to the target application;

[0011] The host machine operating system is controlled to allocate a target host machine physical address corresponding to the target host machine virtual address, and load data corresponding to the target host machine virtual address into the target host machine physical address.

[0012] In a second aspect, an embodiment of the present invention provides a memory preloading processing device, which is applied to a virtual machine manager, and the device includes:

[0013] a collection module configured to collect, at a current prediction moment, a plurality of historical page fault exception information generated when a target application in a client accesses a memory, wherein the plurality of historical page fault exception information includes a plurality of client virtual addresses corresponding to the target application;

[0014] A prediction module, configured to determine, based on the plurality of client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application;

[0015] A loading module is used to determine a target host virtual address corresponding to the target client virtual address on the host side based on the target client virtual address and the storage address of the target client system page table corresponding to the target application; and to control the host operating system to allocate a target host physical address corresponding to the target host virtual address, and load data corresponding to the target host virtual address into the target host physical address.

[0016] In a third aspect, an embodiment of the present invention provides an electronic device comprising: a memory, a processor, and a communication interface; wherein, executable code is stored on the memory, and when the executable code is executed by the processor, the memory preloading processing method described in the first aspect is executed.

[0017] In a fourth aspect, an embodiment of the present invention provides a non-temporary machine-readable storage medium, on which executable code is stored. When the executable code is executed by a processor in an electronic device, at least the memory preloading processing method described in the first aspect can be implemented.

[0018] In a fifth aspect, an embodiment of the present invention provides a memory preloading processing system, including:

[0019] A host machine and a client machine virtualized on the host machine, wherein the host machine includes a virtual machine manager and a host operating system;

[0020] The virtual machine manager is used to execute the memory preloading processing method as described in the first aspect.

[0021] In the solution provided by the embodiment of the present invention, for the target application in any client virtualized on the host machine, multiple historical page fault exception information generated when the target application accesses the memory can be collected at the current prediction moment, and each page fault exception information includes the client virtual address accessed when the exception occurs. Afterwards, based on the multiple client virtual addresses included in the multiple historical page fault exception information, the target client virtual address to be accessed when the target application next time a page fault exception occurs is determined. Furthermore, based on the predicted target client virtual address and the storage address of the target client system page table corresponding to the target application, the target host virtual address corresponding to the target client virtual address on the host side is determined to control the host operating system to allocate the target host physical address corresponding to the target host virtual address, and load the data corresponding to the target host virtual address into the target host physical address, thereby loading the data corresponding to the target client virtual address that may cause a page fault exception in the future into the memory in advance, so as to reduce the processing time of the target application when a page fault exception occurs. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0023] FIG1 is a schematic diagram of a virtualization scenario provided by an embodiment of the present invention;

[0024] FIG2 is a flow chart of a memory preloading processing method provided by an embodiment of the present invention;

[0025] FIG3 is a schematic diagram of an address translation process provided by an embodiment of the present invention;

[0026] FIG4 is a flowchart of a memory preloading processing method provided by an embodiment of the present invention;

[0027] FIG5 is a flowchart of a memory preloading processing method provided by an embodiment of the present invention;

[0028] FIG6 is a flowchart of a memory preloading processing method provided by an embodiment of the present invention;

[0029] FIG7 is a schematic structural diagram of a memory preloading processing device provided by an embodiment of the present invention;

[0030] FIG8 is a schematic structural diagram of an electronic device provided by this embodiment. DETAILED DESCRIPTION

[0031] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention. In addition, the step timing in the following method embodiments is only an example and not a strict limitation.

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

[0033] First, some concepts involved in the embodiments of the present invention are explained.

[0034] Virtualization: A resource management technology that abstracts and transforms a computer's physical resources (such as the CPU, memory, disk space, and I / O devices like network adapters) into a configuration environment that can be partitioned and arbitrarily combined into one or more virtual computers. In this article, it primarily refers to virtual machines (VMs) created within physical machines (such as terminal devices and servers). The physical machine is referred to as the host, the virtual machine as the guest, the host operating system as the host OS, and the guest operating system as the guest OS.

[0035] Virtual Machine Manager (VMM) is a functional component used to create and manage virtual machines, and is also commonly called a hypervisor.

[0036] Virtual memory: A computer system memory management technology that makes applications believe that they have continuous available memory space, but in reality, it is usually divided into multiple physical memory fragments, and some data is temporarily stored on external disk storage and exchanged when needed.

[0037] Extended Page Table (EPT) is a hardware-assisted page table formed in memory virtualization technology.

[0038] Nested Page Table (NPT) is also a hardware-assisted page table formed in memory virtualization technology.

[0039] Guest Virtual Address (GVA).

[0040] Guest Physical Address (GPA).

[0041] Host Virtual Address (HVA).

[0042] Host Physical Address (HPA).

[0043] EPT / NPT page fault: When a client application accesses memory not allocated by the host, that is, when the EPT / NPT fails to hit a certain HPA, a page fault event will be generated to notify the host operating system to take appropriate action.

[0044] gcr3: refers to the cr3 register in the client, which stores the storage address of the client system page table corresponding to an application in the client.

[0045] Memory paging is a memory management mechanism proposed based on the use of MMU. It divides virtual addresses and physical addresses into pages and page frames according to a fixed size (such as 4KB), and ensures that the page and page frame sizes are the same. This mechanism ensures efficient memory access and allows the operating system to perform non-contiguous memory allocation. For an application, when the application starts, some of the data required for its operation (such as code, instructions, etc.) can be loaded from a storage device such as a disk into the memory (that is, loaded into the allocated physical address, that is, the physical page). In addition, when the memory is insufficient, the data in the less frequently used physical addresses can be transferred to a storage device such as a disk. When the data is needed again later, the data can be swapped back from the disk to the memory.

[0046] In actual applications, when an application issues an access request for a specific VA and the CPU fails to successfully find the corresponding PA based on the corresponding page table, it means that the data corresponding to the VA has likely not yet been loaded into memory, that is, the PA corresponding to the VA has not yet been allocated. In this case, a page fault will occur. The operating system will then read the data from disk into memory and instruct the MMU to establish a mapping relationship between the VA and the corresponding PA. In this way, the application can then execute the access request normally based on this mapping relationship. Therefore, in this situation, the application must wait for the required data to be loaded from disk into memory and the mapping relationship to be established before it can continue normal execution, which is a long wait. Similar page fault problems can also be encountered in virtualization scenarios. Therefore, embodiments of the present invention provide a memory preloading solution applicable to virtualization scenarios. In summary, during the execution of an application in a virtual machine, virtual addresses (in virtualization scenarios, these virtual addresses are referred to as GVAs) where page faults may occur in the future are predicted in advance. The data corresponding to these virtual addresses is then preloaded from disk into physical memory, reducing the waiting time required for the application to access the data corresponding to these virtual addresses in the future.

[0047] Figure 1 is a schematic diagram of a virtualization scenario provided by an embodiment of the present invention. As shown in Figure 1, taking a certain electronic device as an example, the electronic device can virtualize multiple virtual machines such as virtual machine 1, virtual machine 2... shown in the figure, and each virtual machine can run multiple applications. For example, application a and application b are running in virtual machine 1 in Figure 1.

[0048] In practical applications, the electronic device may be a device such as a notebook computer, a PC, a server, etc.

[0049] As shown in Figure 1, each virtual machine can include its own operating system: guest OS. The guest OS in different virtual machines can be different or the same. The operating system of the electronic device itself is represented as host OS, which can be different or the same as the guest OS in each virtual machine.

[0050] As mentioned above, because a virtual machine is built using virtualization technology based on the hardware resources of a physical machine (i.e., the aforementioned electronic device), in practice, the electronic device is often referred to as the host machine, and the virtual machine is referred to as the client machine. For the sake of consistency, the following descriptions will use the terms client and host machine.

[0051] As shown in FIG1 , in actual applications, a virtual machine manager (VMM) is run in a host machine to manage each client machine.

[0052] In fact, each client also contains at least one virtual CPU (generally represented as vCPU) and other virtual computing, storage and other resources. Multiple vCPUs in each client can share one physical CPU (generally represented as pCPU) in the host machine, but this is not shown in Figure 1.

[0053] In addition to the host OS and VMM, the host machine also includes hardware resources such as the physical CPU and memory shown in Figure 1.

[0054] For memory access, in the aforementioned virtualization scenarios, two types of page tables are generally used: client system page tables and hardware-assisted page tables (such as the EPT and NPT page tables provided by some memory virtualization technologies). The client system page tables are maintained locally on the client and can be maintained by the guest operating system; the hardware-assisted page tables are maintained by the VMM.

[0055] It should be noted that different client machines will have their own client system page table and hardware-assisted page table, such as the client system page table (represented as guest page table a in the figure) and hardware-assisted page table (represented as EPTa in the figure) corresponding to application a shown in Figure 1.

[0056] The client system page table stores the mapping relationship between GVA and GPA, which is used to complete the address translation from GVA to GPA; the hardware-assisted page table stores the mapping relationship between GPA and HPA, which is used to complete the address translation from GPA to HPA.

[0057] Taking the above-mentioned application a contained in client 1 as an example, when application a performs memory access, an access request containing GVAi is triggered, where GVAi refers to a virtual address of a client to be accessed. Based on the access request, GVAi is first converted to the corresponding GPAi through guest page table a. This address conversion operation is completed on the client 1 side. Afterwards, the CPU converts GPAi to the corresponding HPAi based on EPTa. Afterwards, the corresponding data can be read and written from the HPAi in the memory. It should be noted that although EPTa is maintained by the VMM, the address conversion is completed by the hardware (i.e., the CPU), that is, the mapping relationship between GPA and HPA stored in EPTa is updated by the VMM.

[0058] Among them, client 1 includes a gcr3 register, which stores the storage address of the above-mentioned guest page table a. In fact, guest page table a may be an organizational structure of a multi-level page table, and the gcr3 register stores the storage address of the first-level page table. Since different client system page tables corresponding to different applications are different and have different storage addresses, the addresses stored in the gcr3 registers corresponding to different applications are also different. In the process of converting GVAi to GPAi, the storage address of guest page table a in the gcr3 register corresponding to application a is required. The conversion process can refer to the existing related technology and will not be repeated here.

[0059] During the above memory access process, if the CPU performs address translation on GPAi based on EPTa and fails to find the corresponding HPAi, an EPT page fault will occur. At this point, the CPU will enter root mode and run the VMM. The VMM will then need to handle the page fault exception. Simply put, it controls the host OS to load the data corresponding to GPAi (also known as GVAi) from disk to an idle physical address in memory (also known as HPAi) to form a mapping relationship between GPAi and HPAi. Finally, the VMM updates this mapping relationship to EPTa. In this way, based on the newly added mapping relationship in EPTa, application a can complete the above memory access. However, this will cause application a to wait for an excessively long time.

[0060] The process of the VMM controlling the host OS to load data into the memory will be described in detail in the following embodiments.

[0061] The solution provided by the embodiment of the present invention can overcome the above problems. The solution provided by the embodiment of the present invention is described in detail below.

[0062] FIG2 is a flowchart of a memory preloading processing method provided by an embodiment of the present invention. The method may be executed by the VMM in the host machine shown in FIG1 . As shown in FIG2 , the method may include the following steps:

[0063] 201. At a current prediction moment, collect a plurality of historical page fault exception information generated when a target application in a client accesses memory, wherein the plurality of historical page fault exception information includes a plurality of client virtual addresses corresponding to the target application.

[0064] 202. Determine, based on the multiple client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application.

[0065] 203. Determine a target host virtual address corresponding to the target client virtual address on the host side according to the target client virtual address and a storage address of a target client system page table corresponding to the target application.

[0066] 204. Control the host machine operating system to allocate a target host machine physical address corresponding to the target host machine virtual address, and load data corresponding to the target host machine virtual address into the target host machine physical address.

[0067] In summary, in this embodiment, the VMM obtains the predicted GVA to be accessed the next time a page fault exception occurs based on the GVA contained in multiple historical page fault exception information collected from the target application, and performs address translation through the GVA and the storage address of the page table recorded in the gcr3 corresponding to the target application to obtain the HVA corresponding to the GVA, so that the host OS can perform memory preloading processing based on the HVA, thereby completing the memory preloading processing in the virtualization scenario.

[0068] In this embodiment, the client in step 201 may be any one of multiple clients in the host machine, and the target application may be any one of multiple applications running in the client.

[0069] In fact, during the running of the application in the client, the VMM can periodically predict the GVA that the application in the client will access when it finds a page fault exception in the future.

[0070] In one optional embodiment, the above-mentioned prediction process can be executed locally in the VMM. In another optional embodiment, the above-mentioned prediction process can also be executed in a prediction module, and the prediction results can be provided to the VMM. The prediction module is a functional module running in user mode, and the VMM runs in kernel mode. The interaction between the user-mode prediction module and the kernel-mode VMM can be implemented using existing relevant methods, such as system calls. In practical applications, a pre-trained prediction model (e.g., using a neural network model structure) or a pre-defined prediction algorithm can be used to implement the above-mentioned prediction function, but the present invention is not limited to this.

[0071] In this embodiment, the page fault exception information refers to page fault exceptions generated during the GPA to HPA conversion process, such as EPT / NPT page faults, and does not refer to page fault exceptions generated during the GVA to GPA conversion process on the client side. Page fault exceptions generated on the client side can be handled by the guest OS.

[0072] Historical page fault exception information (EPT / NPT page fault) is actually the exception prompt information generated when the VMM fails to convert the address from GPA to HPA based on, for example, the EPT page table. It is used to describe the address access information of the application at this time, which may include information such as the currently accessed GVA, the corresponding GPA, and the storage address of the client system page table corresponding to the application that implements the GVA to GPA conversion.

[0073] In practice, different applications within the client may have different access patterns to their respective GVA spaces. For example, some applications may exhibit continuous GVA access patterns, while others may exhibit discontinuous GVA access patterns. For example, by analyzing the access patterns of the GVAs accessed each time a page fault occurs within a period of time after the target application begins running, the GVA to be accessed (i.e., the target client virtual address) upon the next page fault can be predicted.

[0074] In actual applications, after the target application is started and runs, it will continuously trigger access requests for different GVAs.

[0075] In this embodiment, taking the target application as application a, as mentioned above, and triggering an access request for GVAi, during the execution of this access request, the guest OS first converts GVAi to GPAi based on the GVA-GPA mapping relationship recorded in guest page table a corresponding to the target application. Subsequently, when the CPU performs address translation of GPAi based on EPTa, if it finds that the HPA corresponding to GPAi has not been allocated, a page fault exception is generated. This page fault exception includes information such as GPAi, GVAi, and the storage address of guest page table a recorded in gcr3 corresponding to application a (actually the storage address of the first-level page table in a multi-level page table). The VMM then handles this page fault exception by loading the data corresponding to GVAi, or GPAi, from disk into the allocated HPAi, as described above.

[0076] In the above example, the VMM can collect the above page fault exception information. Assume that the above page fault exception information is the first page fault exception information generated after application a starts running. If the target GVA to be accessed when the next page fault exception occurs cannot be accurately determined based on this page fault exception information alone, the VMM can continue to collect several subsequent page fault exception information generated by application a.

[0077] When the multiple page fault exception information that has been collected can meet the prediction requirements, the multiple page fault exception information that has been collected at this time is used as the multiple historical page fault exception information corresponding to application a. Thereafter, when a prediction time T1 (referred to as the current prediction time) is reached based on the set prediction period, the multiple GVAs contained in the multiple historical page fault exception information are obtained to determine the target GVA to be accessed when a page fault exception occurs next time in application a based on the multiple GVAs, which is assumed to be GVAj.

[0078] After that, the VMM will load the data corresponding to GVAj into the allocated target host physical address (expressed as HPAj) in advance through the cooperation of the host OS in a process similar to the page fault exception handling mentioned above.

[0079] In fact, during the memory access process of application a in the client, taking the access request of GVAj as an example, in detail, it includes the following address conversion processes: GVAj is converted to GPAj, GPAj is converted to HVAj, and HVAj is converted to HPAj. Among them, the conversion of GVAj to GPAj is completed on the client side based on the client system page table (guest page table a), the conversion of HVAj to HPAj is completed on the host side based on the host system page table (assuming that for application a, the page table is represented as host page table a), and the conversion of GPAj to HVAj is completed by the VMM, that is, the mapping relationship between GPAj and HVAj is maintained in the VMM. For the convenience of description, the page table corresponding to application a that stores the mapping relationship is represented as VMM page table a. The above address conversion process is shown in Figure 3.

[0080] In fact, since VMM can realize the conversion from GPAj to HVAj and host OS can complete the conversion from HVAj to HPAj, it is precisely because of these two software address conversions that EPTa executed in hardware can be constructed.

[0081] In this embodiment, after predicting the above-mentioned GVAj, the VMM needs to determine the HVAj (i.e., the target host virtual address) corresponding to the GVAj based on the GVAj and the storage address of the guest page table a recorded in the above-mentioned gcr3, and then control the host OS to allocate the target host physical address (expressed as HPAj) corresponding to HVAj and load the data corresponding to HVAj into HPAj. In other words, it is necessary to first convert GVAj into HVAj based on the storage address of the guest page table a recorded in gcr3.

[0082] The conversion from GVAj to HVAj is necessary because the host OS actually loads data from disk into physical memory, and the addresses used by the host OS are HVA and HPA. In this scenario, application a running on the client is treated as a normal application process in a non-virtualized scenario. Its memory accesses actually use the virtual addresses provided by the host OS, namely, HVA. For the HVAj that application a currently accesses, the host OS allocates the corresponding HPAj and loads the data corresponding to the HVAj from disk into the HPAj.

[0083] Referring to Figure 3, to convert GVAj to HVAj, you need to first convert GVAj to GPAj, and then convert GPAj to HVAj. Since the mapping relationship between GPA and HVA is maintained by the VMM, after the VMM obtains GPAj, it can determine the corresponding HVAj based on this mapping relationship.

[0084] The conversion of GVAj to GPAj is based on the storage address of the guest page table a recorded in gcr3.

[0085] In an optional embodiment, since the multiple historical page fault exception information corresponding to application a includes multiple GVAs and corresponding multiple GPAs, the VMM can establish a mapping relationship storage record corresponding to the storage address of guest page table a recorded in gcr3 (for ease of description, expressed as the page table base address) based on the multiple historical page fault exception information, wherein the mapping relationship storage record includes the mapping relationship between the above multiple GVAs and GPAs. Based on this, for the above GVAj, it is possible to check whether the mapping relationship storage record contains the GVAj. If it does, the GPAj corresponding to the GVAj can be directly determined from the mapping relationship storage record, and then the HVAj corresponding to the GPAj can be determined based on the mapping relationship between the locally stored GPA and HVA.

[0086] In actual applications, if application a previously generated a page fault exception (EPT / NPT page fault) when accessing GVAj, the historical page fault exception information will include the correspondence between GVAj and GPAj. Later, if the data of GVAj is not used for a long time due to memory space shortage, the data corresponding to GVAj may be swapped out from memory to disk. If GVAj is accessed again, a page fault exception will occur again. In the solution provided by the above optional embodiment, in this example situation, if the predicted GVA is GVAj, GPAj can be directly queried based on the saved record of the mapping relationship that stores the correspondence between GVAj and GPAj.

[0087] When GVAj is not found in the above-mentioned mapping relationship storage record, the solution provided in the following optional embodiment can be optionally adopted. It should be noted that the solution provided in the following optional embodiment can also be implemented independently, that is, it is not limited to being implemented only when GVAj is not found in the above-mentioned mapping relationship storage record.

[0088] In this alternative embodiment, the VMM can send the page table base address to the guest OS to indicate that it is currently processing application a, as different applications have different corresponding page table base addresses. The guest OS reads guest page table a based on the page table base address and determines GPAj corresponding to GVAj based on the GVA-GPA mapping stored in guest page table a. It then provides GPAj to the VMM. The VMM then determines HVAj corresponding to GPAj based on the locally stored GPA-HVA mapping.

[0089] In combination with the above page table base address, the implementation method of completing the conversion from GVAj to HVAj is not limited to the two optional implementation methods exemplified above.

[0090] In summary, in an embodiment of the present invention, each time a page fault exception occurs in a target application in a client, the corresponding GVA and the page table base address stored in gcr3 are recorded. A series of collected GVAs are used as a basis to analyze the GVA to be accessed when the next page fault exception occurs through a certain prediction algorithm. Then, the predicted GVA and the page table base address stored in gcr3 are converted into HVA, and memory preloading is performed in advance on the host side, thereby reducing the impact caused by the page fault exception of the target application on the client side.

[0091] Reducing the impact caused by page fault exceptions can be understood through the following embodiments shown in Figures 4 and 5.

[0092] FIG4 is a flowchart of a memory preloading processing method provided by an embodiment of the present invention. The method may be executed by the VMM shown in FIG1 . As shown in FIG4 , the method may include the following steps:

[0093] 401. At the current prediction moment, collect multiple historical page fault exception information generated when the target application in the client accesses the memory, where the multiple historical page fault exception information includes multiple client virtual addresses corresponding to the target application.

[0094] 402. Determine, based on the predicted input information set including the plurality of client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application.

[0095] 403. Determine a target host virtual address corresponding to the target client virtual address on the host side according to the target client virtual address and the storage address of the target client system page table corresponding to the target application.

[0096] 404. Control the host machine operating system to allocate a target host machine physical address corresponding to the target host machine virtual address, and load data corresponding to the target host machine virtual address into the target host machine physical address.

[0097] 405. In response to the page fault exception information triggered by the target application when accessing the target client virtual address, obtain the target host physical address allocated by the host operating system, determine the target client physical address corresponding to the target client virtual address, and update the mapping relationship between the target client physical address and the target host physical address into the hardware assisted page table corresponding to the target application.

[0098] 406. Update the target client virtual address into the prediction input information set.

[0099] Still taking the target application as application a and the target client virtual address as GVAj in the aforementioned embodiment as an example, after the host OS allocates the above HPAj and loads the corresponding data into HPAj based on HVAj, HPAj can be fed back to the VMM.

[0100] In this embodiment, optionally, after receiving the above-mentioned HPAj, the VMM does not immediately write the mapping relationship between GPAj and HPAj into EPTa, but only temporarily stores the mapping relationship between GPAj and HPAj locally, so as not to affect the defect exception normally generated when application a accesses GVAj. In other words, if application a subsequently accesses GVAj, a page fault exception will be generated because the mapping relationship between GPAj and HPAj does not exist in EPTa. At this time, the VMM searches the local storage record for the mapping relationship between GPAj and HPAj based on GVAj and GPAj contained in the page fault exception information, and then writes the mapping relationship between GPAj and HPAj into EPTa.

[0101] In addition, when the above-mentioned page fault exception occurs when accessing GVAj, GVAj can be updated to the prediction input information set for subsequent prediction of the GVA to be accessed when the page fault exception occurs in the application a.

[0102] In the solution provided by this embodiment, when a page fault occurs while accessing GVAj, because the corresponding data has already been preloaded into memory and its corresponding GPAj has been determined in advance, the VMM only needs to perform a single EPTa update, which takes very little time and does not significantly affect the access latency of application a. While this solution does not truly prevent page faults in application a, by collecting information about page faults normally generated by application a, it can more accurately predict the GVA to be accessed when a subsequent page fault occurs.

[0103] FIG5 is a flowchart of a memory preloading processing method provided by an embodiment of the present invention. The method may be executed by the VMM shown in FIG1 . As shown in FIG5 , the method may include the following steps:

[0104] 501. At the current prediction moment, multiple historical page fault exception information generated when a target application in a client accesses memory is collected, where the multiple historical page fault exception information includes multiple client virtual addresses corresponding to the target application.

[0105] 502. Determine, based on the predicted input information set including the plurality of client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application.

[0106] 503. Determine a target host virtual address corresponding to the target client virtual address on the host side according to the target client virtual address and the storage address of the target client system page table corresponding to the target application.

[0107] 504. Control the host machine operating system to allocate a target host machine physical address corresponding to the target host machine virtual address, and load data corresponding to the target host machine virtual address into the target host machine physical address.

[0108] 505. Obtain the target host physical address assigned by the host operating system, determine the target client physical address corresponding to the target client virtual address, and update the mapping relationship between the target client physical address and the target host physical address into the hardware-assisted page table corresponding to the target application, so that the target application will not trigger a page fault exception message when accessing the target client virtual address.

[0109] 506. In response to the output of the target client virtual address, the target client virtual address is updated into the prediction input information set, so as to be used for predicting the client virtual address to be accessed when a page fault exception occurs next time for the target application at the next prediction moment.

[0110] In this embodiment, taking the target application as application a and the target client virtual address as GVAj in the aforementioned embodiment as an example, after the host OS allocates the above HPAj and loads the corresponding data into HPAj based on HVAj, HPAj can be fed back to the VMM.

[0111] In this embodiment, after obtaining HPAj, VMM can directly update the mapping relationship between GPAj and HPAj into EPTa. In this way, if application a really accesses GVAj later, no page fault exception will be generated and the access can be completed smoothly.

[0112] Based on this, when predicting the GVA to be accessed when application a encounters a page fault exception next time at the next prediction moment, the prediction input information set used will include GVAj predicted output at the previous prediction moment, even if application a may not actually access GVAj.

[0113] In summary, the solutions provided by the embodiments shown in FIG. 4 and FIG. 5 mainly consider the balance between access wait delay caused by page fault exceptions and prediction accuracy.

[0114] FIG6 is a flowchart of a memory preloading processing method provided by an embodiment of the present invention. The method may be executed by the VMM shown in FIG1 . As shown in FIG6 , the method may include the following steps:

[0115] 601. At the current prediction moment, collect a set of historical page fault exception information corresponding to the client, where the set of historical page fault exception information is generated by multiple applications running in the client, wherein each page fault exception information includes a storage address of a client system page table corresponding to the corresponding application.

[0116] 602. Determine multiple page fault exception information corresponding to the storage address of the target client system page table from the historical page fault exception information set as multiple historical page fault exception information corresponding to the target application. The target client system page table corresponds to the target application.

[0117] The target application is any one of multiple applications.

[0118] 603. Determine a target client virtual address to be accessed when a page fault exception occurs next time, based on multiple client virtual addresses included in multiple historical page fault exception information corresponding to the target application.

[0119] 604. Determine a target host virtual address corresponding to the target client virtual address on the host side according to the target client virtual address and the storage address of the target client system page table corresponding to the target application.

[0120] 605 . Control the host machine operating system to allocate a target host machine physical address corresponding to the target host machine virtual address, and load data corresponding to the target host machine virtual address into the target host machine physical address.

[0121] The above embodiments describe the process of VMM preloading memory for the memory access process of the target application. In actual applications, a client often runs multiple applications, and the target application is one of these multiple applications. Memory preloading is required for all of these applications.

[0122] In practice, after each application is started and runs, if a page fault exception occurs, it will trigger the corresponding page fault exception information from the VMM. However, the startup time of each application may vary, and the frequency of page fault exceptions may also vary. Therefore, after a client is started and runs, the VMM can start collecting page fault exception information generated by the client, that is, the page fault exception information generated by all applications started on the client, and form a page fault exception information collection.

[0123] Since the guest page table corresponding to each application is different, the storage address of the guest page table (contained in the corresponding gcr3) contained in the page fault exception information triggered by different applications is different. Therefore, the VMM can use the storage address of the guest page table as the basis for distinguishing the page fault exception information triggered by different applications, and merge the page fault exception information corresponding to the storage address of the same guest page table. For example, the storage address of the guest page table corresponding to the target application is called the storage address of the target guest page table, and the page fault exception information corresponding to the storage address of the target guest page table is merged together to serve as multiple historical page fault exception information corresponding to the target application.

[0124] In actual applications, a threshold value for the number of page fault exception messages can be set in the VMM. Taking the target application as an example, if it is found that the number of page fault exception messages corresponding to the storage address of the target guest page table has reached the threshold value, the prediction processing of the GVA to be accessed when the next page fault exception occurs for the target application will be started.

[0125] The execution of steps 603 - 605 refers to the description in the aforementioned other embodiments and will not be repeated here.

[0126] The communication devices of one or more embodiments of the present invention are described in detail below. Those skilled in the art will appreciate that these devices can be constructed using commercially available hardware components and configured according to the steps taught in this solution.

[0127] FIG7 is a schematic structural diagram of a memory preloading processing device provided by an embodiment of the present invention. The device is applied to the above-mentioned virtual machine manager. As shown in FIG7 , the device includes: a collection module 11 , a prediction module 12 , and a loading module 13 .

[0128] The collection module 11 is used to collect multiple historical page fault exception information generated when the target application in the virtual machine accesses the memory at the current prediction moment, and the multiple historical page fault exception information includes multiple client virtual addresses corresponding to the target application.

[0129] The prediction module 12 is configured to determine, based on the multiple client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application.

[0130] The loading module 13 is used to determine the target host virtual address corresponding to the target client virtual address on the host side based on the target client virtual address and the storage address of the target client system page table corresponding to the target application; and to control the host operating system to allocate the target host physical address corresponding to the target host virtual address, and load the data corresponding to the target host virtual address into the target host physical address.

[0131] Optionally, the device also includes: a first page table update module, used to obtain the target host physical address assigned by the host operating system; determine the target client physical address corresponding to the target client virtual address; and update the mapping relationship between the target client physical address and the target host physical address into the hardware-assisted page table corresponding to the target application, so that the target application will not trigger a page fault exception message when accessing the target client virtual address.

[0132] Optionally, the device also includes: a first prediction update module, used to update the target client virtual address to a prediction input information set in response to the output of the target client virtual address, so as to predict the client virtual address to be accessed when a page fault exception occurs next time for the target application at the next prediction moment, wherein the prediction input information set includes the multiple client virtual addresses.

[0133] Optionally, the device also includes: a second page table update module, which is used to obtain the target host physical address allocated by the host operating system in response to the page fault exception information triggered by the target application when accessing the target client virtual address; determine the target client physical address corresponding to the target client virtual address; and update the mapping relationship between the target client physical address and the target host physical address into the hardware-assisted page table corresponding to the target application.

[0134] Optionally, the apparatus further comprises: a second prediction update module, configured to update the target client virtual address into the prediction input information set in response to page fault exception information triggered when the target application accesses the target client virtual address.

[0135] Optionally, the multiple historical page fault exception information also includes multiple client physical addresses corresponding to the multiple client virtual addresses. The loading module 13 is also used to: establish a mapping relationship storage record corresponding to the storage address of the target client system page table, the mapping relationship storage record includes the mapping relationship between the multiple client virtual addresses and the multiple client physical addresses; determine the mapping relationship storage record according to the storage address of the target client system page table; if the target client virtual address is found from the mapping relationship storage record, determine the target client physical address corresponding to the target client virtual address from the mapping relationship storage record; determine the target host virtual address corresponding to the target client physical address according to the stored mapping relationship between the client physical address and the host virtual address, and the mapping relationship between the client physical address and the host virtual address corresponds to the target application.

[0136] Optionally, the loading module 13 is also used to: send the storage address of the target client system page table to the client operating system, so that the client operating system determines the target client physical address corresponding to the target client virtual address based on the mapping relationship between the client virtual address and the client physical address stored in the target client system page table; determine the target host virtual address corresponding to the target client physical address based on the stored mapping relationship between the client physical address and the host virtual address, and the mapping relationship between the client physical address and the host virtual address corresponds to the target application.

[0137] Optionally, the acquisition module 11 is specifically used to: collect a set of historical page fault exception information corresponding to the client, the set of historical page fault exception information is generated by multiple applications running in the client, wherein each page fault exception information contains the storage address of the client system page table corresponding to the corresponding application, and the target application is any one of the multiple applications; determine multiple page fault exception information corresponding to the storage address of the target client system page table from the set of historical page fault exception information as the multiple historical page fault exception information corresponding to the target application.

[0138] The device shown in FIG7 can execute the steps provided in the aforementioned embodiments. For detailed execution process and technical effects, please refer to the description in the aforementioned embodiments and will not be repeated here.

[0139] An embodiment of the present invention further provides an electronic device, as shown in FIG8 , which may include: a processor 21, a memory 22, and a communication interface 23. The memory 22 stores executable code, and when the executable code is executed by the processor 21, the memory preloading processing method described in the aforementioned embodiment is implemented.

[0140] In addition, an embodiment of the present invention provides a non-temporary machine-readable storage medium, on which executable code is stored. When the executable code is executed by a processor in an electronic device, the memory preloading processing method provided in the aforementioned embodiment can be implemented.

[0141] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiment. Those skilled in the art can understand and implement the present invention without inventive effort.

[0142] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by adding a necessary general hardware platform, and of course can also be implemented by a combination of hardware and software. Based on this understanding, the above technical solution, or the part that contributes to the prior art, can be embodied in the form of a computer product. The present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0143] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A memory preloading processing method, characterized in that: Applied to a virtual machine manager, the method comprises: At the current prediction moment, a plurality of historical page fault exception information generated when a target application in a client accesses a memory is collected, wherein the plurality of historical page fault exception information includes a plurality of client virtual addresses corresponding to the target application; Determine, based on the multiple client virtual addresses, a target client virtual address to be accessed when a page fault exception occurs next time in the target application program; Determine a target host machine virtual address corresponding to the target client machine virtual address on the host machine side according to the target client machine virtual address and a storage address of a target client machine system page table corresponding to the target application program; The host machine operating system is controlled to allocate a target host machine physical address corresponding to the target host machine virtual address, and data corresponding to the target host machine virtual address is loaded into the target host machine physical address.

2. The method according to claim 1, characterized in that The method further comprises: Obtaining the physical address of the target host machine assigned by the host machine operating system; Determine a target client physical address corresponding to the target client virtual address; The mapping relationship between the target client physical address and the target host physical address is updated into the hardware-assisted page table corresponding to the target application so that the target application will not trigger page fault exception information when accessing the target client virtual address.

3. The method according to claim 2, characterized in that The method further comprises: In response to the output of the target client virtual address, the target client virtual address is updated to a prediction input information set for predicting the client virtual address to be accessed when a page fault exception occurs next time for the target application at the next prediction moment, wherein the prediction input information set includes the multiple client virtual addresses.

4. The method according to claim 1, characterized in that: The method further comprises: In response to page fault exception information triggered by the target application when accessing the target client virtual address, obtaining the target host machine physical address allocated by the host machine operating system; Determine a target client physical address corresponding to the target client virtual address; The mapping relationship between the target client physical address and the target host physical address is updated into the hardware-assisted page table corresponding to the target application.

5. The method according to claim 4, characterized in that The method further comprises: In response to page fault exception information triggered by the target application when accessing the target client virtual address, the target client virtual address is updated into the prediction input information set.

6. The method according to any one of claims 1 to 5, characterized in that The plurality of historical page fault exception information also includes a plurality of client physical addresses corresponding to the plurality of client virtual addresses; The method further comprises: establishing a mapping relationship saving record corresponding to a storage address of the target client system page table, wherein the mapping relationship saving record comprises a mapping relationship between the plurality of client virtual addresses and the plurality of client physical addresses; The determining, based on the target client virtual address and the storage address of the target client system page table corresponding to the target application, a target host virtual address corresponding to the target client virtual address on the host side includes: Determine the mapping relationship saving record according to the storage address of the target client system page table; If the target client virtual address is found from the mapping relationship storage record, then determining the target client physical address corresponding to the target client virtual address from the mapping relationship storage record; The target host virtual address corresponding to the target client physical address is determined according to the stored mapping relationship between the client physical address and the host virtual address, and the mapping relationship between the client physical address and the host virtual address corresponds to the target application.

7. The method according to any one of claims 1 to 5, characterized in that The determining, based on the target client virtual address and the storage address of the target client system page table corresponding to the target application, a target host virtual address corresponding to the target client virtual address on the host side includes: Sending the storage address of the target client system page table to the client operating system, so that the client operating system determines the target client physical address corresponding to the target client virtual address according to the mapping relationship between the client virtual address and the client physical address stored in the target client system page table; The target host virtual address corresponding to the target client physical address is determined according to the stored mapping relationship between the client physical address and the host virtual address, and the mapping relationship between the client physical address and the host virtual address corresponds to the target application.

8. The method according to any one of claims 1 to 5, characterized in that The acquisition of multiple historical page fault exception information generated when the target application in the client accesses the memory includes: Collecting a set of historical page fault exception information corresponding to the client, wherein the set of historical page fault exception information is generated by multiple applications running in the client, wherein each page fault exception information includes a storage address of a client system page table corresponding to the corresponding application, and the target application is any one of the multiple applications; A plurality of page fault exception information corresponding to the storage address of the target client system page table is determined from the historical page fault exception information set as the plurality of historical page fault exception information corresponding to the target application.

9. An electronic device, characterized in that: include: A memory, a processor, and a communication interface; wherein the memory stores executable code, and when the executable code is executed by the processor, the memory preloading processing method as described in any one of claims 1 to 8 is executed.

10. A non-transitory machine-readable storage medium, characterized in that: The non-transitory machine-readable storage medium stores executable code, and when the executable code is executed by a processor in an electronic device, the memory preloading processing method according to any one of claims 1 to 8 is executed.

11. A memory preloading processing system, characterized in that: include: A host machine and a client machine virtualized on the host machine, wherein the host machine includes a virtual machine manager and a host machine operating system; The virtual machine manager is used to execute the memory preloading processing method according to any one of claims 1 to 8.

Images