Pre-installing page table cache rows on a virtual machine

Pre-installing memory address mappings in a higher memory hierarchy addresses the performance bottleneck of VM switching by ensuring faster access, enhancing processor efficiency and throughput.

DE112016003466B4Active Publication Date: 2025-12-11INTERNATIONAL BUSINESS MACHINE CORPORATION
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
DE112016003466
Authority / Receiving Office
DE · DE
Patent Type
Patents
Current Assignee / Owner
Priority Date
2015-10-28
Filing Date
2016-09-27
Publication Date
2025-12-11
Estimated Expiration
2036-09-27

AI Technical Summary

Technical Problem

Switching between virtual machines (VMs) in data processing systems is slowed by the need to retrieve memory address mappings from slower storage units like hard drives, which can result in slower storage devices, which can require accessing slower storage units, such as hard drives, leading to performance degradation.

Method used

Pre-installing memory address mappings for the new VM by moving them from a lower level to a higher level in the memory hierarchy closer to the processor, such as cache or main memory, before switching VMs, thereby reducing the need to retrieve mappings from slower storage.

Benefits of technology

This approach reduces the time required to perform memory address translations, improving processor performance and throughput by keeping necessary mappings in faster cache or main memory, thus avoiding slower storage access.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

Procedures, exhibiting: Running an initial operating system (OS), corresponding to an initial virtual machine (VM), using a processor for an initial predefined period; Pre-installing page table entries before the first predefined period expires, corresponding to a second OS of a second VM, by moving the page table entries from a lower level to an upper level of a memory hierarchy, the upper level being closer to the processor in the memory hierarchy than the lower level; and After the first predefined period has expired, the second OS, corresponding to the second VM, is executed using the processor for a second predefined period.
Need to check novelty before this filing date? Find Prior Art

Description

BACKGROUND

[0001] The present invention relates to warming up a data processing system when switching between virtual machines (VMs). In particular, the present disclosure relates to pre-installing stored memory address mappings before running a new VM.

[0002] Processors typically contain at least one memory management unit (MMU) for performing mappings from virtual to physical addresses. For example, the processor can allocate blocks of virtual memory to different processes running on the processor (such as operating systems or user applications). Each virtual address corresponds to a physical memory address in main memory. The mappings between virtual and physical addresses are stored in a page table as page table entries. The page table is typically stored in main memory.

[0003] When a process sends a request to a processing kernel to read from or write data to a specific virtual address, the MMU queries the page table (or an address translation buffer) to identify the corresponding physical address. The processing kernel then uses the physical address to perform the read or write operation requested by the process.

[0004] JP 2008 - 293 472 A describes a computer device and a cache recovery method designed to prevent cache errors in an environment where multiple virtual machines are operated.The computer device comprises a high-speed cache; a memory area for storing data to be transferred to the high-speed cache; a memory area for storing history information in which addresses are associated with identifiers that uniquely identify virtual computers; a decision area which, upon switching virtual computers, uses the memory area to check whether the identification number in the history data matches the identification number of the virtual computer after the switch, and uses the address associated with the matching identification number to identify the data stored in the memory area and transfer the identified data to the high-speed cache; and a transfer instruction area. BRIEF SUMMARY OF THE INVENTION

[0005] One embodiment of the present invention is a method comprising running a first operating system (OS), corresponding to a first virtual machine (VM), using a processor for a first period. The method includes pre-installing, before the first period expires, page table entries corresponding to a second OS of a second VM by moving the page table entries from a lower level to an upper level of a memory hierarchy, the upper level being closer to the processor in the memory hierarchy than the lower level. After the first period has expired, the method comprises running the second OS, corresponding to the second VM, using the processor for a second period.

[0006] Another embodiment of the present invention is a data processing system comprising a processor configured to run a first operating system corresponding to a first virtual machine (VM) for a first period, and a hypervisor. The hypervisor is configured to pre-install page table entries corresponding to a second VM's operating system before the first period expires, by moving the page table entries from a lower level to an upper level of a memory hierarchy, the upper level being closer to the processor in the memory hierarchy than the lower level. After the first period expires, the hypervisor also instructs the processor to begin running the second VM's operating system for a second period.

[0007] Another embodiment of the present invention is a computer program product for switching between VMs, wherein the computer program product includes executable computer code to instruct a processor to run a first OS corresponding to a first VM for a first period of time, and before the end of the first period of time, to pre-install page table entries corresponding to a second OS of a second VM by moving the page table entries from a lower level to an upper level of a memory hierarchy, the upper level being closer to the processor in the memory hierarchy than the lower level. After the first period of time has elapsed, the computer code is executable to instruct the processor to run the second OS corresponding to the second VM for a second period of time. Brief description of the different views of the drawings Fig. Figure 1 is a block diagram of a data processing system which, according to an embodiment described herein, pre-installs memory address mappings when switching between virtual machines. Fig. 2 is a flowchart for pre-installing memory address mappings when switching between virtual machines according to an embodiment described herein. Fig. Figure 3 is a block diagram of a data processing system which, according to an embodiment described herein, stores memory address mappings when switching from a virtual machine. Fig. Figure 4 is a block diagram of a data processing system that switches between different virtual machines according to an embodiment described herein. Fig. Figure 5 is a block diagram of a data processing system which, according to an embodiment described herein, pre-installs memory address mappings before switching between virtual machines. Fig. Figure 6 is a block diagram of a data processing system that switches between different virtual machines according to an embodiment described herein.

[0008] For clarity, identical reference numerals have been used, where possible, to denote identical elements common to the figures. It is considered that elements disclosed in one embodiment may be advantageously used in other embodiments without being specifically cited again. DETAILED DESCRIPTION

[0009] The embodiments described herein pre-install memory address mappings used to perform mappings from virtual to physical memory addresses (or vice versa) in a data processing system that switches between virtual machines (VMs). For example, a processor (or CPU) in the data processing system can run different VMs at different times. In other words, the processor's processing time can be allocated to or divided among multiple VMs. In one embodiment, the processor executes instructions for a first VM during a first period and then switches to executing instructions for a second VM during a second period.

[0010] In some cases, the VMs are unrelated. Specifically, the memory address mappings used by processes running in the first VM may differ from those used by processes running in the second VM. For example, the first and second VMs may run different processes assigned to different virtual memory addresses. In this case, the page table entries required to perform virtual-to-physical address mappings for the processes running in the first VM will differ from those required to perform virtual-to-physical address mappings for the processes running in the second VM.When the processor switches between VMs, the page table entries cached in the cache memory while the previous VM was running are replaced by the page table entries corresponding to the new VM. However, this can require accessing slower storage units (e.g., a hard drive), which slows down the execution of the new VM.

[0011] The implementations described herein pre-install the memory address mappings for the new virtual machine (VM) to be executed. In other words, before switching the processor from the current VM to the new one, a hypervisor can retrieve pre-stored memory address mappings for the new VM and load them into the cache or main memory. When the new VM starts running, the corresponding memory address mappings are thus located in the cache instead of in memory. If these memory address mappings are needed to perform mappings from virtual to physical addresses, the data processing system does not need to retrieve the memory address mappings from slow storage devices (e.g., hard disk drives), thereby saving hundreds of thousands of processor cycles.

[0012] In one embodiment, the data processing system includes an address translation buffer (TLB) for performing conversions from virtual to physical memory addresses. The TLB is a cache memory used by an MMU to store a subset of the page table entries. If an address is not in the TLB (i.e., a failed TLB), the data processing system performs a page walk operation to locate the address in another cache memory or main memory. Because the embodiments described herein pre-install the previously stored memory address conversions in the cache memory, the desired address may be stored in the cache memory in the event of a failed TLB. As explained above, this saves the time required to retrieve the address information from memory.In other words, when switching between VMs, the memory address mappings already stored in the TLB are likely not very useful for the new VM. Therefore, the implementations described herein pre-install memory address mappings specific to the new VM in a cache or main memory. Instead of having to retrieve the page table entries from memory after a failed TLB, this data can be found in the cache. Pre-installing the memory address mappings in the cache thus "warms up" the TLB for the new VM, as failed TLBs may require less time to resolve.

[0013] Fig. Figure 1 is a block diagram of a data processing system 100 which, according to an embodiment described herein, pre-installs memory address mappings when switching between VMs. In particular, the data processing system 100A on the far left illustrates the state of the data processing system before the memory address mappings are pre-installed in a cache memory 120, whereas the data processing system 100B on the far right illustrates the state of the data processing system after the memory address mappings have been pre-installed in the cache memory 120.

[0014] Data processing system 100 contains a hypervisor 105, a VM 107A, a VM 107B, a processor 115, cache memory 120, and memory 125. The hypervisor 105 (i.e., a virtual machine monitor) is software and / or hardware that manages and runs the VMs 107 (also known as logical partitions or LPARs) in data processing system 100. Generally, the hypervisor 105 acts as an intermediary between the VMs 107 and the hardware in data processing system 100—for example, the processor 115. As shown, OS 110A is the operating system for VM 107A, whereas OS 110B is the operating system for VM 107B.

[0015] In one embodiment, the hypervisor 105 controls which VM 107 (and its corresponding OS 110) is currently being executed by the processor 115. In other words, the hypervisor 105 can schedule the processing time of the processor 115 so that different processing time blocks are allocated to different VMs 107 in the data processing system 100. In this example, VM 107A is currently scheduled to use the processor 115. Therefore, the processor 115 executes instructions provided by the processes running in OS 110A, as indicated by the dashed box in the processor 115. Although Fig. As illustrated by Figure 1, which shows only two VMs (Figure 107), the data processing system (Figure 100) can contain any number of VMs that share processing time on the processor (Figure 115).

[0016] Processor 115 represents any number of processing elements, each of which can contain one or more processing cores. If Processor 115 contains multiple cores, the VMs 107 can, in one embodiment, be scheduled to use the individual cores in different time blocks. For example, OS 110A of VM 107A can be scheduled to use the first core in Processor 115, whereas OS 110B of VM 107B can be scheduled to use the second core in Processor 115. Alternatively, the VMs 107 can use the entire Processor 115 (which contains multiple cores) during their scheduled time period. For example, all cores in Processor 115 can execute instructions issued by OS 110A. While VM 107A is scheduled to use Processor 115, OS 110B of VM 107B can be inactive—that is, not running.Hypervisor 105 blocks the processes running on OS 110B until their scheduled time to use processor 115.

[0017] The cache memory 120 can be any memory element located between the processor 115 and the memory 125. The cache memory 120 and the memory 125 form part of a memory hierarchy for the data processing system 100A. In one embodiment, the cache memory 120 stores a subset of the data stored in the memory 125. When executing a read or write request, the processor 115 can first search for the data in the cache memory 120 before searching for the data in the memory 125. Although the cache memory 120 is typically smaller than the memory 125, access to the memory elements that comprise the cache memory 120 can be faster.For example, the cache memory 120 could consist of RAM or flash memory, while the memory 125 could be a hard disk drive, tape drive, external data storage server, cloud storage, or another non-volatile storage device.

[0018] In one embodiment, the cache memory 120 can consist of memory elements in the integrated circuit (IC) that form the processor 115—e.g., cache memory L1, cache memory L2, cache memory L3, etc. In another embodiment, the cache memory 120 can be a main memory (e.g., a random-access memory (RAM) unit containing DRAM or SRAM) located on a motherboard in the data processing system 100. Although not shown, the cache memory 120 can store a page table containing page table entries corresponding to the processes executed by the OS 110A. The processor 115 can use these page table entries to map virtual addresses to physical addresses (and vice versa).

[0019] In Fig. Memory 1 contains 125 memory address mappings 130 for OS 110B. Thus, even though processor 115 is currently running OS 110A, data processing system 100 has previously stored memory address mappings 130 corresponding to OS 110B. As described in more detail below, data processing system 100 may have stored the memory address mappings 130 when processor 115 was previously running OS 110B.

[0020] As shown in the data processing system 100B on the far right, the hypervisor 105 moves the memory address mappings 130 for OS 110B into the cache memory 120. In one embodiment, the hypervisor 105 moves the memory address mappings 130 in response to determining that the time scheduled for VM 107A to use processor 115 is nearing its end, and that VM 107B is next in line to use processor 115. In other words, before processor 115 switches from running OS 110A to OS 110B, the hypervisor 105 begins moving the memory address mappings 130 closer to processor 115 in the memory hierarchy.Since OS 110A and 110B can run different processes that use different virtual address spaces before the memory address mappings 130 are moved from memory to cache memory 120, cache memory 120 can only store memory address mapping information for OS 110A. This means that during the execution time of OS 110A on processor 115, all memory address mappings for OS 110B may already have been removed from cache memory 120.

[0021] In one embodiment, the data processing system 100 can use a Longest Unused Retention (LRU) policy to determine which memory address mappings should be retained in cache memory 120 and which should be invalidated—that is, moved to memory 125. Since the memory address mappings, corresponding to the virtual addresses used by OS 110B, are not used when OS 110A is running in processor 115, these memory address mappings are marked by the hypervisor and removed from cache memory 120. Therefore, when hypervisor 105 switches from running OS 110A to running OS 110B, cache memory 120 can contain only memory address mappings for OS 110A. As in Fig. As shown in Figure 1, the hypervisor 105 pre-installs selected memory address mappings 130 for OS 110B in the cache memory 120. Therefore, when OS 110B begins execution on processor 115, at least some memory address mappings 130, corresponding to OS 110B, are already in the cache memory 120 and can thus be accessed more quickly than if processor 115 had to wait for the memory address mappings to be retrieved from memory 125. Therefore, pre-installing the memory address mappings 130 can increase the throughput of processor 115 when switching from running OS 110A to OS 110B compared to a data processing system that does not pre-install memory address mappings in the cache memory 120.

[0022] Fig. Figure 2 is a flowchart of a method 200 for pre-installing memory address mappings when switching between VMs according to an embodiment described herein. For simplicity, the various blocks of method 200 are referred to in conjunction with the Fig. Figures 3 to 6 discuss various examples corresponding to Method 200. In Block 205, the hypervisor stores memory address mappings in a page table, corresponding to a first VM, in a log file. In one embodiment, the hypervisor stores the memory address mappings during the time scheduled for the first VM to use the processor in the data processing unit. Suppose that a predefined block of time is specified for the first VM to use the processor; then the hypervisor begins storing memory address mappings belonging to the OS for the first VM as soon as the hypervisor determines that the first VM has, for example, only 10% of its time remaining.

[0023] Fig. Figure 3 is a block diagram of a data processing system 300 that, according to an embodiment described herein, stores memory address mappings when switching from a virtual machine (VM). As shown in this example, the processor 115 is currently running the OS 110B corresponding to the VM 107B. Since the scheduled time for the VM 107B is about to expire, the hypervisor 105 begins storing some of the entries 310 of a page table for the OS 110B. In particular, the hypervisor 105 stores one or more selected page table entries 320 for the OS 110B in a log 315. Although the log 315 is shown in memory 125, the log may also reside in a cache memory located further away from the processor 115 in the hierarchy than the cache memory 120. For example, cache memory 120 can be a special cache memory used to store page tables, whereas log 315 is stored in main memory.In one embodiment, the hypervisor 105 stores the selected page table entries 320 for the current OS, which is running in a memory location that is not overwritten when the next VM starts running on the processor 115.

[0024] The data processing system 300 also includes a TLB 305 for performing the virtual-to-physical address mappings requested by the processor 115. In one embodiment, the TLB 305 can be considered a type of cache memory that stores only a portion of the entries 310 in the page table for the OS 110B. For example, the TLB 305 can be an associative memory (e.g., content-addressable memory (CAM)) that is higher in the memory hierarchy than the cache memory 120—that is, the TLB 305 is closer to the processor 115 than the cache memory 120. Therefore, when a memory address mapping is performed, the processor 115 first queries the TLB 305 to determine if the virtual-to-physical address mapping is stored there. If not, the processor 115 iterates through the page table entries 310 in the cache memory 120. However, it is possible that the cache memory is 120 (e.g.The main memory does not have enough memory elements to store all page tables corresponding to the entire virtual address space of the data processing system 300. For example, the cache memory 120, such as the TLB 305, can only store a portion of the page table entries for the data processing system 300. Therefore, if the cache memory 120 does not have the required allocation, the processor 115 can retrieve the virtual address from memory 125, which can contain copies of all page tables in the data processing system 300.

[0025] Hypervisor 105 can use a variety of techniques to determine which page table entries 310 should be stored in log 315 before the scheduled time for VM 107B expires. In one embodiment, Hypervisor 105 selects the page table entries stored in TLB 305 as the page table entries 320 stored in log 315. This means that since in many data processing systems TLB 305 stores the page table entries that the data processing system expects or predicts will most likely be needed in the future to perform memory address mappings, Hypervisor 105 can store the page table entries of TLB 305 in log 315. Therefore, when VM 107B is scheduled to use processor 115 again, this list of entries will be retained in log 315.

[0026] In another embodiment, the hypervisor 105 identifies the page table entries that were most recently used (MRU) by the processor 115 when address translations were performed to store data in protocol 315. For example, the hypervisor 105 can select only the page table entries that were accessed by the processor 115 to perform a memory address translation within the last 50 milliseconds. Alternatively, the hypervisor 105 can maintain a counter for each of the page table entries 310, indicating how many times each entry was used to perform a memory address translation while OS 110B was running. The hypervisor 105 can select only the page table entries with a counter count greater than a minimum counter count. In yet another example, the hypervisor 105 can limit the number of selected page table entries 320 to a fixed set (e.g.,(only five megabytes) and select the entries with the highest counter counts until the fixed amount is reached - i.e., select the first five megabytes of entries with the highest counter counts.

[0027] The examples provided above for selecting page table entries 320 for the currently running OS are not intended as limiting examples. A person skilled in the art will recognize that there are many different techniques for selecting page table entries that are most likely to be accessed by the operating system when the corresponding VM is scheduled to run again on processor 115. Furthermore, in one embodiment, the hypervisor 105 can store all page table entries 310 for OS 110B in protocol 315, instead of selecting a subset of the page table entries stored in cache memory 120.

[0028] Although in Fig. 3. If the selected page table entries 320, which are stored in log 315, are identified before the time scheduled for VM 107B has elapsed, the hypervisor 105 can, in a further embodiment, select one or more page table entries 320 after the time has elapsed. For example, there may be a standstill period between the termination of OS 110B's execution and the commencement of OS 100A's execution by processor 115. During this period, the hypervisor 105 can select which page table entries 320 should be stored in log 315. Furthermore, the hypervisor 105 can select some or all of the page table entries 320 to be stored in log 315 after processor 115 has begun executing OS 110A.Since it may take some time before the processor 115 has replaced the page table entries currently in TLB 302 and cache memory 120 with page table entries according to OS 110A, the hypervisor 105 may have time to evaluate the entries in TLB 305 and / or cache memory 120 to determine which entries should be stored in log 315.

[0029] Referring again to procedure 200, in block 210 the processor switches from running the first VM to running a second VM. As mentioned above, each VM in a data processing system can be allocated a specific time block for execution. Therefore, for the time block allocated to the VM, the processor executes received instructions for the OS corresponding to that VM, while the other VMs are inactive. That is, the processor does not execute instructions for the unscheduled VMs.

[0030] Fig. Figure 4 is a block diagram of a data processing system 300 that, according to an embodiment described herein, has switched between VMs 107. In contrast to Fig. 3. Processor 115 in Data Processing System 300 now executes instructions received from OS 110A instead of OS 110B. Because TLB 305 caches page table entries for OS 110B—that is, the operating system previously running on Processor 115—many, if not all, of the conversion requests forwarded by Processor 115 for OS 110A result in cache errors. In response, Data Processing System 300 performs a page walk operation on the page table entries stored in cache memory 120—for example, in Data Processing System 300's main memory. However, cache memory 120 may have limited storage capacity—that is, it may only be able to store a fixed number of page table entries.In one embodiment, the data processing system 300 can limit the amount of cache memory 120 that can be used to store page table entries. For example, the cache memory can be a main working memory in which 2% of the cache memory 120 is reserved for page table entries, while the other 98% is reserved for data requested by the operating systems 110. Therefore, the data processing system 300 might not be able to store the page table entries for all of the different virtual machines 107 in the cache memory 120.

[0031] For example, the cache memory can be 120 in Fig. 3 primarily stores the page table entries 310 for OS 110B. Consequently, many of the requests for a memory address translation, which are forwarded by an MMU in the processor 115, result in errors in the cache memory 120. In response, the data processing system 300 can retrieve the page table entries, according to OS 110A, from memory 125, which can take hundreds of thousands of processor cycles.

[0032] Fig. Figure 4 illustrates the result of the data processing system 300, which replaces the entries previously stored in cache memory 120 with the page table entries 405 for OS 110A. Although not shown, the entries in TLB 305 can also be updated to include page table entries for OS 110A instead of OS 110B. Therefore, conversion requests forwarded by processor 115 are more likely to result in matches in TLB 305 or cache memory 120, eliminating the need to query memory 125. This can increase the speed at which processor 115 completes instructions, since accessing page table entries stored in TLB 305 and cache memory 120 may require far fewer processing cycles than accessing data from memory 125.

[0033] Referring again to procedure 200, in block 215 the hypervisor loads the memory address mappings corresponding to the first VM into a memory level closer to the processor before the timeout of the second VM expires. That is, while the processor is still executing instructions for the OS corresponding to the second VM, the hypervisor begins loading memory address mappings corresponding to the OS of the first VM from a lower to a higher level of the memory hierarchy—for example, from memory to main memory.

[0034] Fig. Figure 5 is a block diagram of a data processing system that, according to an embodiment described herein, pre-installs memory address mappings before switching between VMs. Fig. In step 5, processor 115 is still executing instructions received from OS 110A. However, hypervisor 105 has moved the selected page table entries 310 for OS 110B from protocol 315 in memory 125 to cache memory 120. In one embodiment, hypervisor 105 can begin moving the selected page table entries 320 to cache memory 120 at a predefined time before switching VM 107A to VM 107B—for example, one microsecond before the switch, or when VM 107A has only 5% of its time remaining. In another example, the hypervisor might not be able to move all entries 320 to cache memory 120 before processor 115 switches to running OS 110B.Nevertheless, hypervisor 105 at least begins moving page table entries 320 for OS 110B to cache memory 120 before processor 115 finishes executing instructions for OS 100A, even if entries 320 have not yet been completely moved to cache memory 120 before OS 110B begins execution. In other words, hypervisor 105 begins the copying process for the page table entries for OS 110B to cache memory 120 before the processing time for VM 107A is complete.

[0035] In one embodiment, the hypervisor can stop moving the selected page table entries 320 into the cache memory 120 while the processor 115 is still running OS 110A. Since the size of the cache memory 120 may be limited (or the number of entries in the cache memory for page table entries may be fixed), the hypervisor 105 can selectively determine which of the page table entries 405 for OS 110A should be removed to free up memory space for the page table entries 320 for OS 110B. In other words, the hypervisor 105 selects which of the page table entries 405 for OS 110A should be replaced by the page table entries 320 for OS 110B.

[0036] In one embodiment, the hypervisor 105 can determine which of the page table entries 405 are least likely to be used by the processor 115 while running OS 110A for the remaining time allocated to VM 107A. This hopefully prevents the hypervisor 105 from having to remove a page table entry 405 for OS 110A, which would then have to be retrieved from memory 125, thus slowing down the execution of OS 110A. In other words, the hypervisor 105 can predict which page table entries 405 in the processor 115 are least likely to be used while running OS 110A and can remove only those entries 405 from the page table to make room for the page table entries 320 for OS 110B.

[0037] In one embodiment, the hypervisor 105 uses a least-used-out (LRU) algorithm to select the page table entries 405 to be removed from the cache memory 120. Specifically, the hypervisor 105 selects the page table entries 405 that are least frequently used by the processor 115 to perform memory address translations and replaces these entries with page table entries 320 for OS 110B. In another example, by monitoring historical data, the hypervisor 105 can identify which page table entries are typically accessed (and which are not) when the processor 115 stops running OS 110A and can remove only the infrequently used entries. For example, the processor 115 can perform the same management operations when switching between VMs 107 that use the same page table entries.By identifying which of the page table entries 405 are used during the management operations, the hypervisor 105 can retain these entries in the cache memory 120 while removing the others. The person skilled in the art will recognize that these are only some examples of the various techniques for predicting which page table entries will be used in the future that can be applied to the embodiments described herein.

[0038] Although Fig. Figure 5 illustrates moving the page table entries 320 for OS 110B from memory 125 to cache memory 120. In another embodiment, the page table entries 320 can be moved to TLB 305 before hypervisor 105 switches from VM 107A to VM 107B. That is, hypervisor 105 can replace one or more of the entries in TLB 305 with one or more page table entries 320 for OS 110B. Although replacing all entries in TLB 305 with entries 320 for OS 110B may not be desirable, as this considerably increases the likelihood that the conversion requests forwarded when running OS 110A will result in a faulty TLB, replacing some of the entries may reduce the likelihood that memory 125 will need to be queried for a page table entry when processor 115 starts running OS 110B.

[0039] Furthermore, if the processor 115 switches from running OS 110A to OS 110B in one embodiment, the hypervisor 105 can remove the remaining page table entries 405 for OS 110A from the cache memory 120 and / or the TLB 305. For example, if the hypervisor 105 knows that page table entries for OS 110A are never or almost never used when running OS 110B, the hypervisor 105 can proceed to remove the remaining entries in the cache memory 120 or the TLB 305 and replace them with the selected page table entries 320. In one embodiment, the hypervisor 105 can move the page table entries 320, which were stored in the cache memory 120 while OS 110A was still running on the processor 115, into the TLB 305 as soon as the processor 115 stops running OS 110A and starts running OS 110B.

[0040] When page table entries 320 are moved to cache 120, the data processing system selects page table entries 505 for OS 110A that are stored in cache 120 and / or TLB 305 and stores these entries in log 315. When switching back to VM 107A, hypervisor 105 can thus move the entries 505 for OS 110 from log 315 to cache 120 or TLB 305, as explained above. In one example, the hypervisor 105 can select which of the entries 505 for OS 110A should be stored in protocol 315, in parallel with moving the selected page table entries 320 for OS 110B from protocol 315 to a higher level of the memory hierarchy - i.e., the cache memory 120 or the TLB 305.

[0041] Referring again to procedure 200, the processor queries the loaded memory address mappings at block 220 to perform a mapping of virtual to physical addresses for the first VM after switching to the first VM. In other words, instead of having to wait for a TLB failure and a cache error before moving page table entries out of memory for the first VM, the data processing system has already begun moving at least some of the page table entries for the first VM out of memory to a memory level closer to the processor—for example, main memory or the TLB.In one embodiment, some of the page table entries for the first VM are already stored in main memory or the TLB, increasing the likelihood that the data processing system will not need to access memory to fulfill memory address translation requests that were forwarded while instructions forwarded by the OS to the first VM were executing. Moving the page table entries for the first VM from memory to a higher level in the memory hierarchy is referred to here as warming up the TLB.Even if the page table entries for the first VM are not actually moved to the TLB before the processor starts executing the first VM's OS, the TLB still warms up because the implementations described herein, when the processor starts executing the OS, improve the probability that a faulty TLB will not require memory retrieval. Instead, at least some of the page table entries for the first VM can reside in a cache—for example, in main memory—which can be accessed much faster.

[0042] Fig. Figure 6 is a block diagram of a data processing system 300 that switches between different VMs according to an embodiment described herein. As shown, the processor 115 has been running OS 110A (as in Fig. (5 shown) to the execution of OS 110B. In this example, the page table entries for OS 110A were removed from cache memory 120 and replaced by page table entries 605 for OS 110B. In one embodiment, after OS 110B has been executed for a sufficient period of time, it is possible that all page table entries 405 for OS 110A in cache memory 120 have been replaced solely by page table entries 605 for OS 110B. Likewise, although not shown, the entries in TLB 305 can be changed relative to the entries in TLB 305 to the one in Fig. The point in time shown in point 5 has been replaced.

[0043] Although some of the page table entries 605 for OS 110B may have been pre-installed in cache memory 120, as in Fig. As shown in Figure 5, the remaining portion of entries 605 can be loaded after processor 115 begins executing OS 110B—that is, when data processing system 300 switches from executing VM 107A to executing VM 107B. For example, processing element 115 might forward a conversion request containing a virtual address that does not correspond to any of the pre-installed page table entries. In this case, data processing system 300 retrieves the corresponding page table entry from memory 125. Thus, while some of the page table entries 605 may be pre-installed in cache memory 120 (and / or TLB 305), data processing system 300 can retrieve other page table entries for OS 110B from memory after processor 115 has begun executing OS 110B.

[0044] When the processing time for VM 107B begins to run out, procedure 200 can be repeated. That is, before switching back to VM 107A, hypervisor 105 can save the entries selected from page table entries 605 to log 315, as shown in Fig. Figure 3 shows that, in anticipation of the switch from VM 107A to VM 107B, Hypervisor 105 can begin pre-installing the selected page table entries 505 for OS 110A, stored in log 315, in cache memory 120. As mentioned above, Hypervisor 105 can remove some of the page table entries 605 for OS 110B from cache memory 120 to make room for the selected page table entries 505.

[0045] The descriptions of the various embodiments of the present invention have been prepared for illustrative purposes; they are by no means intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations are obvious to those skilled in the art, which do not deviate from the scope of protection and the inventive concept of the described embodiments. The terminology used herein has been chosen to explain, as clearly as possible, the basic ideas of the embodiments, their practical application, or technical improvements compared to technologies found on the market, or to enable other skilled persons to understand the embodiments disclosed herein.

[0046] The foregoing refers to embodiments presented in this disclosure. However, the scope of protection of this disclosure is not limited to specific embodiments described. Instead, any combination of the features and elements described above, regardless of whether they relate to different embodiments, is considered for implementing and carrying out the embodiments under consideration. Although embodiments disclosed herein may further acquire advantages over other possible solutions or over the prior art, the attainment or non-attainment of a particular advantage by a specific embodiment does not constitute a limitation of the scope of protection of this disclosure.Therefore, the aspects, features, embodiments, and advantages described herein are for illustrative purposes only and are not to be considered as elements or limitations of the claims in the Annex, except where they are explicitly cited in a claim (or claims). Likewise, reference to "the invention" should not be construed as a generalization of any subject matter disclosed herein and should not be considered as an element or limitation of the claims in the Annex, except where they are explicitly cited in a claim (or claims).

[0047] Aspects of the present invention may be in the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects, all of which may be generally referred to herein as a “circuit”, “module” or “system”.

[0048] The present invention may be a system, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium (or storage media) containing computer-readable program code to induce a processor to execute aspects of the present invention.

[0049] The computer-readable storage medium can be a concrete unit capable of retaining and storing instructions for use by an instruction execution unit. For example, a computer-readable storage medium can be, but is not limited to, an electronic storage unit, a magnetic storage unit, an optical storage unit, an electromagnetic storage unit, a semiconductor storage unit, or any suitable combination thereof.A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer floppy disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static working memory (SRAM), a portable CD-ROM, a DVD drive (DVD), a memory stick, a floppy disk, a mechanically encrypted unit such as punched cards or raised structures in a groove with instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, need not be designed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g.,Light pulses passing through an optical fiber cable) or electrical signals transmitted through a wire.

[0050] The computer-readable program instructions described herein can be downloaded to respective data processing units from a computer-readable storage medium or to an external computer or storage device via a network, such as the internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission lines, fiber optic cables, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each data processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium within the respective data processing unit.

[0051] Computer-readable program instructions for performing operations of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or other source code or object code written in any combination of one or more programming languages, including Smalltalk, C++, or the like, and conventional procedural programming languages ​​such as the programming language "C" or similar programming languages. The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In the latter scenario, the remotely located computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be established to an external computer (for example, via the internet using an internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute the computer-readable program instructions using state information from the computer-readable program instructions to personalize the electronic circuit in order to implement aspects of the present invention.

[0052] Aspects of the present invention are described herein with reference to illustrations of the flowchart and / or block diagrams of processes, devices (systems), and computer program products according to embodiments of the invention. It is understood that each block in the illustrations of flowcharts and / or block diagrams, and combinations of blocks in the illustrations of flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0053] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other devices that process programmable data to create a machine such that the instructions executed via the processor of the computer or other devices that process programmable data create means for carrying out the functions / actions specified in the flowchart and / or block or blocks of the block diagram.These computer-readable program instructions can also be stored in a computer-readable storage medium capable of controlling a computer, programmable data processing device and / or other units to function in a particular manner, such that the computer-readable storage medium with the instructions stored therein constitutes a manufactured item, including instructions that implement the function / action specified in the flow chart and / or the block or blocks of the block diagram.

[0054] The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other unit to cause the execution of a series of operations on the computer, other programmable device, or other unit to produce a computer-implemented process, such that the instructions executed on the computer, other programmable device, or other unit implement the functions / actions specified in the flowchart and / or block(s) of the block diagram.

[0055] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, processes, and computer program products according to various embodiments of the present invention. In this respect, each block in the flowchart or block diagrams can represent a module, segment, or section of instructions comprising one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions specified in the block may occur out of the order shown in the figures. For example, two blocks shown consecutively may actually be executed essentially in parallel, or the blocks may sometimes be executed in reverse order, depending on the functionality involved.It is also noted that each block of the block diagrams and / or illustration of the flowchart and combinations of blocks in the block diagrams and / or illustration of the flowchart can be implemented by special systems based on hardware that perform the specified functions or actions, or execute combinations of special hardware and computer instructions.

[0056] Although the foregoing refers to embodiments of the present invention, other and further embodiments of the invention are conceivable without deviating from its basic scope of protection, and their scope of protection is defined by the following claims.

Claims

[1] Method, comprising: Running an initial operating system (OS), corresponding to an initial virtual machine (VM), using a processor for an initial predefined period; Pre-installing page table entries before the first predefined period expires, corresponding to a second OS of a second VM, by moving the page table entries from a lower level to an upper level of a memory hierarchy, the upper level being closer to the processor in the memory hierarchy than the lower level; and After the first predefined period has expired, the second OS, corresponding to the second VM, is executed using the processor for a second predefined period. [2] Method according to claim 1, wherein, when the first OS is executed during the first predefined period, the second OS is inactive, and when the second OS is executed during the second predefined period, the first OS is inactive. [3] Method according to claim 1, wherein the moving of the page table entries from the lower level to the upper level comprises: Moving page table entries from a log file in a storage unit to a random access memory (RAM) unit. [4] Method according to claim 1, further comprising: Execute the second OS before the first and second predefined periods expire, using the processor during a third period; and Select, before the first predefined period, one or more page table entries, according to the second OS, to be stored in the lower level of the memory hierarchy. [5] Method according to claim 4, wherein the selection of one or more page table entries, according to the second OS, comprises: Determining the one or more page table entries that were last used (MRU) in order to perform a memory address translation when the second OS is running on the processor during the third period. [6] Method according to claim 4, further comprising: Saving one or more selected page table entries to a non-volatile storage device before starting to run the first OS during the first predefined period. [7] Method according to claim 1, wherein the pre-installation of the page table entries, according to the second OS of the second VM, comprises: Select, before moving the page table entries from the lower level to the upper level, one or more page table entries in the upper level, according to the first OS, using a Longest Unused Requirement (LRU) algorithm; and Remove, before moving the page table entries from the lower level to the upper level, one or more selected page table entries, according to the first OS, from the upper level of the memory hierarchy. [8] Data processing system comprising: a processor configured to run an initial operating system (OS) corresponding to an initial virtual machine (VM) for an initial predefined period; and a hypervisor that is configured to: Pre-install, before the first predefined period expires, page table entries corresponding to a second OS of a second VM, by moving the page table entries from a lower level to an upper level of a memory hierarchy, the upper level being closer to the processor in the memory hierarchy than the lower level; and Instruct the processor, after the first predefined period has expired, to begin running the second OS corresponding to the second VM for a second predefined period. [9] Data processing system according to claim 8, wherein, when the first OS is running during the first predefined period, the second OS is inactive, and when the second OS is running during the second predefined period, the first OS is inactive. [10] Data processing system according to claim 8, wherein the hypervisor is configured, when the page table entries are moved from the lower level to the upper level, to move the page table entries from a log file in a storage unit to a random access memory (RAM) unit. [11] Data processing system according to claim 8, wherein the hypervisor is configured to: Instructing the processor, before the first and second predefined periods expire, to run the second OS during a third period; and Select, before the first predefined period, one or more page table entries, according to the second OS, to be stored in the lower level of the memory hierarchy. [12] Data processing system according to claim 11, wherein the selection of one or more page table entries, according to the second OS, comprises: Determining the one or more page table entries that were last used (MRU) in order to perform a memory address translation when the second OS is running on the processor during the third period. [13] Data processing system according to claim 11, wherein the hypervisor is configured to: Saving one or more selected page table entries to a non-volatile storage device before starting to run the first OS during the first predefined period. [14] Computer program product for switching between virtual machines (VMs), wherein the computer program product comprises: a computer-readable storage medium containing computer-readable program code, wherein the computer-readable program code is executable by one or more computer processors for: Instructing a processor to run an initial operating system (OS), corresponding to an initial virtual machine (VM), for an initial predefined period of time; Pre-install, before the first predefined period expires, page table entries corresponding to a second OS of a second VM, by moving the page table entries from a lower level to an upper level of a memory hierarchy, the upper level being closer to the processor in the memory hierarchy than the lower level; and After the first predefined period has expired, instruct the processor to run the second OS corresponding to the second VM using the processor for a second predefined period. [15] Computer program product according to claim 14, wherein when the first OS is running during the first predefined period, the second OS is inactive, and when the second OS is running during the second predefined period, the first OS is inactive. [16] Computer program product according to claim 14, wherein the computer-readable program code is further executable for: Instructing the processor, before the first and second predefined periods expire, to run the second OS during a third period; and Select, before the first predefined period, one or more page table entries, according to the second OS, to be stored in the lower level of the memory hierarchy. [17] Computer program product according to claim 14, comprising pre-installing the page table entries according to the second OS of the second VM: Select, before moving the page table entries from the lower level to the upper level, one or more page table entries in the upper level, according to the first OS, using a Longest Unused Requirement (LRU) algorithm; and Remove, before moving the page table entries from the lower level to the upper level, one or more selected page table entries, according to the first OS, from the upper level of the memory hierarchy.

Citation Information

Patent Citations

  • JP002008293472A