Hypervisor scheduler
Techniques for configuring a hypervisor scheduler to make use of cache topology of processors and physical memory distances between NUMA nodes when making scheduling decisions. In the same or other embodiments the hypervisor scheduler can be configured to optimize the scheduling of latency sensitive workloads. In the same or other embodiments a hypervisor can be configured to expose a virtual cache topology to a guest operating system running in a virtual machine.
BACKGROUND
A virtual machine may have one or more virtual processors that are exposed to a guest operating system as single core processors. When a guest operating system runs a workload, it schedules a thread on a virtual processor. A hypervisor runs and schedules a thread that represents the virtual processor on a logical processor of a physical machine that hosts the VM (virtual machine). The workload in the thread runs and some, hopefully useful, work is performed. The hypervisor then runs another thread on the same, or a different logical processor. The hypervisor scheduler thus must determine both when and where to schedule a particular virtual processor. Proper placement of the virtual processors is a key to maintaining high levels of performance.
Currently, hypervisors treat the logical processors the same. For example, a hypervisor may schedule a virtual processor to run in a first NUMA node (Non-Uniform Memory Architecture node) and then move it to another NUMA node. This technique ensures that workloads are run as fast as possible and any overhead due to cache misses is tolerated.
The decision to expose virtual processors as single core processors was made to make virtualization of the physical architecture of the host machine easier. For example, guest operating systems are written so that the topology is checked on boot. If the guest was moved to another host with a different topology it may operate inefficiently because the resources it expects are no longer present.
As systems that include logical processors that share various different caches become more common, it would be beneficial to configure a hypervisor to leverage them. Moreover, it would be beneficial to expose some sort of cache topology to a guest operating system so that the scheduler in the guest operating system can also make intelligent scheduling decisions.
SUMMARY
Techniques are disclosed for configuring a hypervisor to leverage the physical cache topology of a host computer system. In an exemplary embodiment, the hypervisor is configured to make use of processor topology, cache hierarchies, and the distance between memories. For example, in an exemplary embodiment, a method includes an operation for causing a list of idle logical processors to be generated in response to receiving a request to schedule a thread indicative of a virtual processor of a virtual machine; and an operation for causing the thread indicative of the virtual processor to be scheduled on a logical processor from the list that shares a level of cache with a seed logical processor.
In another exemplary embodiment, a method includes an operation for exposing a plurality of single core virtual processors to a virtual machine; an operation for generating a list of idle logical processors in response to receiving a request to execute a thread indicative of a single core virtual processor; an operation for identifying logical processors currently executing threads indicative of single core virtual processors of the virtual machine; and an operation for scheduling the thread indicative of the virtual processor on a logical processor from the list that shares a cache with a maximum number of logical processors currently executing the threads indicative of the single core virtual processors of the virtual machine.
An yet another exemplary embodiment, a method includes an operation for causing a thread indicative of a virtual processor of a virtual machine to be assigned a distinct logical processor to execute thereon; an operation for causing a list of idle logical processors to be generated in response to receiving a request to execute the thread indicative of a virtual processor; and an operation for causing the thread indicative of the virtual processor to be scheduled on a logical processor that shares a level of cache with the distinct logical processor assigned to execute the thread indicative of the virtual processor. In addition to the foregoing, other aspects are described in the claims, drawings, and text forming a part of the disclosed subject matter.
It can be appreciated by one of skill in the art that one or more various aspects described herein may include but are not limited to circuitry and/or programming for effecting the herein-referenced aspects described herein; the circuitry and/or programming can be virtually any combination of hardware, software, and/or firmware configured to effect the herein-referenced aspects depending upon the design choices of the system designer.
The foregoing is a summary and thus contains, by necessity, simplifications, generalizations and omissions of detail. Those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 depicts an example computer system wherein the subject matter described herein can be implemented.
FIG. 2 depicts an operational environment wherein the subject matter described herein can be implemented.
FIG. 3 depicts an operational environment wherein the subject matter described herein can be implemented.
FIG. 4 illustrates a datacenter wherein the subject matter described herein can be implemented.
FIG. 5 depicts an operational environment wherein the subject matter described herein can be implemented.
FIG. 6 depicts operational procedure.
FIG. 7 depicts an alternative embodiment of the operational procedure of FIG. 6.
FIG. 8 depicts operational procedure.
FIG. 9 depicts an alternative embodiment of the operational procedure of FIG. 8.
FIG. 10 depicts operational procedure.
FIG. 11 depicts an alternative embodiment of the operational procedure of FIG. 10.
FIG. 12 depicts an operational procedure.
FIG. 13 depicts an alternative embodiment of the operational procedure of FIG. 12.
DETAILED DESCRIPTION
Embodiments may execute on one or more computer systems. FIG. 1 and the following discussion are intended to provide a brief general description of a suitable computing environment in which the disclosed subject matter may be implemented.
Referring now to FIG. 1, an exemplary computing system 100 is depicted. Computer system 100 can include logical processor 102, e.g., an execution core. While one logical processor 102 is illustrated, in other embodiments computer system 100 may have multiple logical processors, e.g., multiple execution cores per processor substrate and/or multiple processor substrates that could each have multiple execution cores. As shown by the figure, various computer readable storage media 110 can be interconnected by one or more system busses that couple various system components to the logical processor 102. The system buses may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. In example embodiments, the computer readable storage media 110 can include for example, random access memory (RAM) 104, storage device 106, e.g., electromechanical hard drive, solid state hard drive, etc., firmware 108, e.g., FLASH RAM or ROM, and removable storage devices 118 such as, for example, CD-ROMs, floppy disks, DVDs, FLASH drives, external storage devices, etc. It should be appreciated by those skilled in the art that other types of computer readable storage media can be used such as magnetic cassettes, flash memory cards, and/or digital video disks.
The computer readable storage media 110 can provide nonvolatile and volatile storage of executable instructions 122, data structures, program modules and other data for the computer 100 such executable instructions that effectuate manager 250described in the following figures. A basic input/output system (BIOS) 120, containing the basic routines that help to transfer information between elements within the computer system 100, such as during start up, can be stored in firmware 108. A number of programs may be stored on firmware 108, storage device 106, RAM 104, and/or removable storage devices118, and executed by logical processor 102 including an operating system and/or application programs.
Commands and information may be received by computer 100 through input devices 116 which can include, but are not limited to, a keyboard and pointing device. Other input devices may include a microphone, joystick, game pad, scanner or the like. These and other input devices are often connected to logical processor 102 through a serial port interface that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or universal serial bus (USB). A display or other type of display device can also be connected to the system bus via an interface, such as a video adapter which can be part of, or connected to, a graphics processor unit 112. In addition to the display, computers typically include other peripheral output devices (not shown), such as speakers and printers. The exemplary system of FIG. 1 can also include a host adapter, Small Computer System Interface (SCSI) bus, and an external storage device connected to the SCSI bus.
Computer system 100 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer. The remote computer may be another computer, a server, a router, a network PC, a peer device or other common network node, and typically can include many or all of the elements described above relative to computer system 100.
When used in a LAN or WAN networking environment, computer system 100 can be connected to the LAN or WAN through network interface card 114. The NIC 114, which may be internal or external, can be connected to the system bus. In a networked environment, program modules depicted relative to the computer system 100, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections described here are exemplary and other means of establishing a communications link between the computers may be used. Moreover, while it is envisioned that numerous embodiments of the disclosed subject matter are particularly well-suited for computerized systems, nothing in this document is intended to limit the disclosed subject matter to such embodiments.
Turning to FIG. 2, hypervisor microkernel 202 can be configured to control and arbitrate access to the hardware of computer system 200. Broadly, hypervisor microkernel 202 can generate execution environments called partitions such as child partition 1 through child partition N (where N is an integer greater than 1). In embodiments a child partition is the basic unit of isolation supported by hypervisor microkernel 202. That is, each child partition can be mapped to a set of hardware resources, e.g., memory, devices, logical processor cycles, etc., that is under control of the hypervisor microkernel 202 and hypervisor microkernel 202 can isolate processes in one partition from accessing another partition's resources, e.g., a guest operating system in one partition may be isolated from the memory of another partition and thus may not be able to detect memory addresses outside of its partition. In embodiments, hypervisor microkernel 202 can be a stand-alone software product, a part of an operating system, embedded within firmware of the motherboard, one or more specialized integrated circuits, or a combination thereof.
Hypervisor microkernel 202 can enforce partitioning by restricting a guest operating system's view of system memory. Guest memory is a partition's view of memory that is controlled by a hypervisor. The guest physical address can be backed by system physical address (SPA), i.e., the memory of the physical computer system, managed by hypervisor. In an embodiment, the GPAs and SPAs can be arranged into memory blocks, i.e., one or more pages of memory. When a guest writes to a block using its page table, the data is actually stored in a block with a different system address according to the system wide page table used by hypervisor.
In the depicted example, parent partition component 204, which can also be also thought of as similar to domain 0 of Xen's open source hypervisor, can interact with hypervisor microkernel 202 to provide a virtualization layer. Parent partition 204 in this operational environment can be configured to provide resources to guest operating systems executing in the child partitions 1-N by using virtualization service providers 228 (VSPs) that are typically referred to as back-end drivers in the open source community. Broadly, VSPs 228 can be used to multiplex the interfaces to the hardware resources by way of virtualization service clients (VSCs) (typically referred to as front-end drivers in the open source community) and communicate with the virtualization service clients via communication protocols. As shown by the figures, virtualization service clients can execute within the context of guest operating systems. These drivers are different than the rest of the drivers in the guest in that they may be supplied with a hypervisor, not with a guest.
As shown by the figure emulators 234, e.g., virtualized integrated drive electronics device (IDE devices), virtualized video adaptors, virtualized NICs, etc., can be configured to run within the parent partition 204 and are attached to resources available to guest operating systems 220 and 222. For example, when a guest OS touches a register of a virtual device or memory mapped to the virtual device 202, microkernel hypervisor can intercept the request and pass the values the guest attempted to write to an associated emulator.
Each child partition can include one or more virtual processors (230 and 232) that guest operating systems (220 and 222) can manage and schedule threads to execute thereon. Generally, the virtual processors are executable instructions and associated state information that provide a representation of a physical processor with a specific architecture. For example, one virtual machine may have a virtual processor having characteristics of an Intel x86 processor, whereas another virtual processor may have the characteristics of a PowerPC processor. The virtual processors in this example can be mapped to logical processors of the computer system such that the instructions that effectuate the virtual processors will be backed by logical processors. Thus, in an embodiment including multiple logical processors, virtual processors can be simultaneously executed by logical processors while, for example, other logical processors execute hypervisor instructions. The combination of virtual processors and memory in a partition can be considered a virtual machine.
Guest operating systems can include any operating system such as, for example, operating systems from Microsoft®, Apple®, the open source community, etc. The guest operating systems can include user/kernel modes of operation and can have kernels that can include schedulers, memory managers, etc. Generally speaking, kernel mode can include an execution mode in a logical processor that grants access to at least privileged processor instructions. Each guest operating system can have associated file systems that can have applications stored thereon such as terminal servers, e-commerce servers, email servers, etc., and the guest operating systems themselves. The guest operating systems can schedule threads to execute on the virtual processors and instances of such applications can be effectuated.
Referring now to FIG. 3, it illustrates an alternative architecture to that described above in FIG. 2. FIG. 3 depicts similar components to those of FIG. 2; however in this example embodiment the hypervisor 304 can include the microkernel component and components from the parent partition 204 of FIG. 2 such as the virtualization service providers 228 and device drivers 224 while management operating system 302 may contain, for example, configuration utilities used to configure hypervisor 304. In this architecture hypervisor 304 can perform the same or similar functions as hypervisor microkernel 202 of FIG. 2; however, in this architecture hypervisor 304 can be configured to provide resources to guest operating systems executing in the child partitions. Hypervisor 304 of FIG. 3 can be a standalone software product, a part of an operating system, embedded within firmware of the motherboard or a portion of hypervisor 304 can be effectuated by specialized integrated circuits.
Briefly, FIG. 4 depicts an operational environment for implementing the disclosed subject matter. For example, a number of computer systems 404-410 can be coupled together in a datacenter 400 (While four computer systems are depicted, one of skill in the art can appreciate that datacenter 400 can include more or fewer computer systems). The depicted computer systems can have different topologies and, moreover, they can have different characteristics, e.g., different amounts of RAM, different RAM speeds, different amount of logical processors, and/or logical processors with different speeds or instruction sets.
As shown by the figure, computer system 406 has a symmetric multiprocessing topology (SMP) or a 'flat' topology. Generally, SMP is a computer architecture that includes a plurality of processors that are connected to a single shared memory. In this arraignment, a memory controller can manage the flow of data to and from memory. Memory access may be uniform with respect to each logical processor and each logical processor can access the entire range of memory, i.e., system physical addresses. This topology works well for computer systems with a relatively small number of processors, but when the computer system includes many processors, all competing for access to the shared memory bus, performance of the system can decrease. Moreover, the complexity of the computer system significantly increases which in turn drives the price per processor up.
Computer systems 404, 408, and 410 have NUMA nodes. NUMA based computer systems are can be generally thought of as computers that are made up of smaller computer systems. In this example, each NUMA node can include one or more logical processors and local memory. The memory inside of a NUMA node is considered local memory and memory in other NUMA nodes is considered remote memory because the only the processors inside of the node are connected to the same memory bus. The NUMA nodes are interconnected by cache coherency domain interconnects which allow processors in one NUMA node to access memory in other NUMA nodes in a coherent way. Thus, system physical addresses are uniform with respect to each processor. Or put another way, system physical address 20,000 is the same for every processor in the computer system. The difference is that for some processors memory address 20,000 is a local memory address, e.g., inside their NUMA node, and for other processors memory address 20,000 is remote, e.g., outside their NUMA node. Generally, local memory can be accessed faster than remote memory and the relationship between local v. remote access time is called a NUMA ratio. A NUMA ratio of 1 to 2 means that it costs twice as many processor cycles to access a particular remote system physical address than a local system physical address. NUMA alleviates bottlenecks caused by SMP systems by limiting the number of processors on any one memory bus and is generally less expensive than a SMP computer system with the same amount of logical processors.
Turning to FIG. 5, it illustrates an operational environment wherein the disclosed subject matter can be implemented. As one skilled in the art can appreciate, the disclosed subject matter does not have to be implemented in a computer system having the illustrated architecture. Instead, the illustrated architecture is merely an exemplar used to explain concepts. Accordingly, the disclosed subject matter can be incorporated into different environments including different amounts of NUMA nodes, virtual machines, cache topologies, logical processors, etc.
FIG. 5 shows two example NUMA nodes (500 and 502) connected by a cache coherency domain interconnect. The illustrated NUMA nodes have different cache topologies. For example, each processor in NUMA node 500 shares level 3 ("L3") cache and two groups of processors share a level 2 ("L2") cache. Each processor (506-516) is shown with its own level 1 ("L1") cache. Logical processors (518-524) in NUMA node 502 share a level 3 cache and have their own level 1 cache. Those of skill in the art can appreciate that the illustrated cache topologies are for illustration purposes only and the disclosed subject matter is not limited to being implemented in a system with any particular cache topology. Each NUMA node (500 and 502) is also shown as including its own random access memory (526 and 528).
Processor cache is typically used for temporary storage of instructions and data herein referred to as information. When a request is made, a logical processor requires instructions for executing that request and data to execute the instruction with. Since the logical processor operates at speeds greater than RAM, high speed caches have been added to processors and algorithms have been devised to anticipate what information a logical processor will need and attempt to store it in caches. Typically, level 1 cache is very small, which allows it to be very fast having latency times of, for example, two cycles, i.e., the number of processor cycles needed to access the memory and retrieve the information. If the information is not present in L1 cache, a cache miss occurs and the logical processor checks its L2 cache, which is a slightly larger pool of memory with a little longer latency of around, for example, nine cycles. If the data is not in L2 or L1, the logical processor checks its L3 cache. L3 cache is far larger than L1 and L2 and its latency is, for example, twenty three cycles. With each cache miss logical processor looks to its next level of cache until it has to fetch the information from RAM or mass storage.
Hypervisor 550, i.e., microkernel hypervisor 202 of FIG. 2 or hypervisor 304 of FIG. 3, can include scheduler 552 which can be configured to schedule threads indicative of virtual processors to run on one of the logical processors (506-516 or 518-524). In order to determine how to schedule an incoming thread, hypervisor scheduler 552 can access various information (554-562) described in more detail below.
Thread table 560, which could be a data structure stored in memory, can store information about the different virtual processor threads. When a request to run a virtual processor is received, scheduler 552 can access thread table 560 and retrieve information about the virtual processor in order to determine where and how to schedule it. For each virtual processor, thread table 560 may store, for example, a timestamp identifying when the thread last ran, whether the thread has been identified to be a latency sensitive thread, the logical processor the thread last ran on, the identity of an ideal processor for the thread, the NUMA node the thread last ran in, information that describes the identity of related virtual processor threads, etc.
In an exemplary embodiment, thread table 560 can be used by scheduler 552 to schedule virtual processor threads. For example, scheduler 552 can be configured to select an idle processor to run an incoming thread that is located within a seed NUMA node, e.g., an ideal NUMA node, or the node that last ran the thread. In this example embodiment, scheduler552 can check thread table 560 to determine the seed NUMA node for an incoming thread request and schedule the thread on the seed NUMA node.
In a specific example, each NUMA node can maintain a per-NUMA node idle processor map (554 and 562). For example, an idle processor map can be a bitmap where each bit represents a logical processor. When a logical processor runs a thread, it can set the bit and when it finishes running the thread, it can reset the bit. The idle processor map can be used byscheduler 552 to determine which logical processors are idle. In an exemplary embodiment, the bitmap can be broken into multiple maps: one for each NUMA node in the computer system stored in the NUMA node. This embodiment reduces the collisions on the map because it reduces the number of processors attempting to access the same memory to set and reset bits.
Moreover, by maintaining a map for each NUMA node, scheduler 552 can quickly remove logical processors from a list of candidates by checking the idle processor map associated with a specific NUMA node. For example, an incoming thread may have its seed NUMA node set as NUMA node 500 in thread table 560, i.e., the thread may have last ran on that node or a processor in the node is set as an ideal processor. Scheduler 552 can receive this information and search idle processor map 554 for an idle processor. In this example scheduler 552 eliminated logical processors 518-524 from a list of candidates without having to access idle processor map 562 or process any information in it.
In the event that the seed NUMA node does not have an idle processor, scheduler 552 can be configured to search for an idle processor from the next closest NUMA node by accessing information in NUMA node table 558, which can be a data structure stored in memory. For example, NUMA node table 558 can include a node distance graph for each NUMA node in the computer system. Hypervisor 550 can generate an array that ranks the NUMA nodes according to memory distance. For example, the graph for NUMA node 500 would show that NUMA node 502 is close. Hypervisor 550 can generate the graph for each node when the host system boots. For example, hypervisor 550 can direct each logical processor in a NUMA node to access RAM from all the other nodes in the host; record the round trip times and rank the times from best to worst; the best time indicating the closest node and the worst time indicating the farthest node.
Once a NUMA node is selected by scheduler 552, various algorithms can be used to select a specific logical processor. In a simple example, one where the virtual machine has one virtual processor, scheduler 552 can determine the seed logical processor for a thread and if that thread is unavailable, scheduler 552 can access a cache hierarchy table 556 to determine where to schedule the thread. Cache hierarchy table 556 can include an array of bitmaps for each logical processor that describes how it shares caches with other logical processors in its NUMA node. For example, logical processor 506 may have 3 arrays (one for L1, L2, and L3 caches) an L1 array that has a bit set for logical processor 506 and nulls for 508-516, an array for L2 that has a bit set for LP 506-510, and an array for L3 that shows bits set for LPs 506-516. In an example, scheduler 552 can be configured to select an idle logical processor that shares a highest level of cache with the seed. For example, if the seed is LP 506 scheduler 552 could select LP 508, LP 510, or LP 512 if any is idle since L2 is the highest cache these processors share.
In an exemplary embodiment, the seed logical processor can be set to the last processor that ran the thread. For example, if a virtual machine includes one logical processor it most efficiently runs on the logical processor that last ran it because this logical processor has the highest chance of having information the virtual processor needs in its cache. In this example embodiment as the virtual processor is moved the seed can be changed to the logical processor that last ran it.
The complexity of the scheduling algorithm can increase as the number of virtual processors assigned to a virtual machine increases. For example, when a virtual machine includes multiple virtual processors it has been noticed by the inventors that they tend to use the same information. Thus, if the virtual processors are scheduled on logical processors that share caches the number of cache hits increases which causes the guest to run more efficiently. In this example, scheduler 552 can select logical processors to run virtual processors of a virtual machine in such a way that the virtual processors share physical caches. This technique reduces the chance that cache misses occur and in the event that one does occur, the information fetched for one virtual processor can be used by the other virtual processors. This technique additionally reduces coherence miss costs. For example, if a virtual processor needs exclusive access to the cache line, the cost of transferring the cache line from the logical processor running the virtual processor to another logical processor is reduced since the information can be moved through their shared cache rather than having to be written all the way back to memory or sent through an inter-socket bus.
In an exemplary embodiment, one where multiple virtual processors are executing within a virtual machine, each virtual processor can be assigned a seed logical processor set by an administrator or automatically by a configuration program. For example, virtual processor 534 could have LP 506 set as its ideal and virtual processor 536 could have its ideal LP set to be LP 508. When scheduler 552 attempts to schedule virtual processor 534, scheduler 552 will determine that it's ideal is LP 506 and attempt to schedule it on LP 506. Since scheduler 552 is attempting to keep threads on their ideal logical processors the number of cache hits will be increased.
In another example embodiment scheduler 552 may not use a seed. Instead, hypervisor scheduler 552 can select an idle logical processor based on the location of threads of other virtual processors in a virtual machine such as virtual machine530. In this example, scheduler 552 can be configured to select a logical processor that it estimates will have the smallest estimated miss cost. A cache miss occurs when a logical processor attempts to access information from a cache and the information is not in cache. The miss cost is the amount of cycles that would be wasted if information is not in cache. In this example embodiment scheduler 552 can select the logical processor that has the lowest estimated miss cost.
For example, scheduler 552 can be configured to select an idle processor that shares cache with a maximum number of logical processors currently running virtual processors of a virtual machine. In the same, or another example, scheduler 552can be configured to select an idle processor that shares a maximum number of caches with a maximum number of logical processors currently running virtual processors of a virtual machine. In yet another exemplarily embodiment, scheduler 552can be configured to select the logical processor that shares the highest level of cache with the most logical processors currently running virtual processors of a virtual machine. For example, and referring to FIG. 5, in an embodiment virtual processor 534 may be running on logical processor 506, virtual processor 536 may be running on logical processor 508 and virtual processor 538 may be running on logical processor 514. In this example scheduler 552 may receive a request to run virtual processor 540. Scheduler 552 can check idle processor map 554 and determine that logical processors 510 and 516are free. In this example scheduler 552 can access cache hierarchy table 556 and obtain the arrays for logical processors510 and 516. Scheduler 552 can determine, based on information in the arrays, that logical processor 510 shares L3 cache with LP 506, LP 508, and LP 514 and logical processor 516 share L3 cache with the same LPs. In the first example above, scheduler 552 may select either LP 510 or 514. In the alternative embodiment described above, scheduler 552 can select LP 510 since it shares L2 cache with LP 506 and 508 as well as L3 cache with LP 506, LP 508, and LP 514. In this example LP 510 shares 5 caches with LP 510 whereas LP 514 shares 3. In the third example, scheduler 552 can select LP510 since it shares L2 cache with LP 506 and 508.
In another example embodiment scheduler 552 can be configured to handle latency sensitive workloads differently than regular workloads when scheduling. Typically virtual processors belonging to latency sensitive guests are scheduled as soon as possible. However in this case if the last logical processor a virtual processor ran on is unavailable, the virtual processor would be migrated elsewhere and the positive effects of having cache hits would be lost. In an example embodiment scheduler 552 can be configured to maximize locality while simultaneously limited latency without affecting non-latency sensitive workloads.
For example, when hypervisor 550 receives a request to schedule a latency sensitive thread, scheduler 552 can determine if there are any logical processors that share cache with the last logical processor that ran the thread and select one. For example, the selected logical processor could be the logical processor that shares the highest level of cache with the processor that last ran the thread. If, no logical processors that share cache are available, scheduler 552 can determine the amount of time since the virtual processor last ran and compare it to a predetermined threshold. If the amount of time since it is last ran is greater than the threshold the virtual processor can be migrated, otherwise it can be queued to run on the logical processor that last ran the thread. If the amount of time since the virtual processor last ran is greater than the threshold, it is assumed that useful information is not in cache. If the amount of time since it last ran is less than the threshold, the assumption is that cache still contains useful information. One skilled in the art can appreciate that the predetermined threshold can be set by a policy or an administrator and is dependent on the physical hardware and workload characteristics of the virtual machine. Over time an administrator or policy can adjust the predetermined threshold and monitor how efficiency increases or decreases until an optimum value is found for a particular host running a particular workload.
Continuing with the description of FIG. 5, in an embodiment, a virtual cache topology can be exposed to virtual machines. In this example embodiment hypervisor 550 can generate a virtualized topology that can be exposed to the guest. Hypervisor550 can construct a topology that can be reasonably honored by the host computer system and, for example, any other computer system in a datacenter. This allows for a scheduler in the guest operating system to make intelligent scheduling decisions while maintaining the abstraction between hardware and virtual hardware.
For example, in an embodiment where virtualized topology is exposed to guest operating system 532, hypervisor 550 can detect the cache topology of the host computer system during boot. In an example embodiment, one where the host is by itself, hypervisor 550 can be configured to compute a virtual cache topology that can be honored by at least most of the logical processors in the computer system. In a datacenter, the host computer can send cache topology to management system 402 along with all the other computers in the datacenter. Management system 402 can then calculate a virtual topology that can be honored by at least most of the computer systems. The topology can be received by hypervisor 550which can effectuate a virtual machine having the topology.
In a specific example, hypervisor 550 or management system 402 can calculate a virtual topology. For example, hypervisor550 or management system 402 can calculate a virtual topology by determining an amount of logical processors shared by a cache; expose the determined number to guest operating system; and expose a cache interconnecting the determined number that is the lowest type of cache that can be honored.
In an exemplary embodiment, and turning to FIG. 5, hypervisor 550 or management system 402 can calculate a virtual cache topology by determining an amount of logical processors shared by a cache (sharing cardinality); expose the sharing cardinality to a guest operating system; and expose a cache interconnecting the determined number that is the highest level of cache that can be honored (sharing level) to a guest operating system.
In one method of calculating sharing cardinality, the sharing cardinality is set as the minimum number of LPs sharing the lowest level of cache in a NUMA node. For example, and referring to FIG. 5, in the illustrated embodiment, hypervisor 550could detect that six LPs in NUMA node 500 and four LPs in NUMA node 502 share the lowest level cache (L3). Hypervisor550 (or in a datacenter example, the management system 402) can then determine that the minimum amount of logical processors that share the lowest level of cache in the cluster is four, e.g., LPs 518-524 share L3. In this example, hypervisor 550 can select L3 as the type of cache to expose because hypervisor 550 (or management system 402) determines the sharing level as the highest level of cache at which there are at least sharing cardinality number of cache sharing LPs. Thus, as illustrated by FIG. 5, in this example, hypervisor 550 can expose groups of four virtual processors that share a virtual L3 cache. Hypervisor 550 can then store the information in cache hierarchy table 556.
In another method of calculating sharing cardinality, the sharing cardinality is the greatest common divisor of each NUMA node's number of LPs sharing the lowest level of cache in each cluster. For example, and referring to FIG. 5, in the illustrated embodiment, hypervisor 550 could detect the numbers of logical processors that as a group share the lowest level of cache in the cluster. In this example, NUMA node 500 includes six LPs (LPs 506-516) that share the lowest level cache, L3, and in NUMA node 502, four LPs (LPs 518-524) share the lowest level cache, L3. Hypervisor 550 (or in a datacenter example, the management system 402) then determines that the greatest common divisor of the two groups, six processors and four processors, is two processors. Hypervisor 550 (or management system 402) then determines that the highest level of cache in each NUMA node at which there are at least the determined number of processors (two in this example) is L3. In this example, hypervisor 550 can select L3 as the type of cache to expose. Thus, as illustrated by FIG. 5, in this example, hypervisor 550 can expose groups of two virtual processors that share a virtual L3 cache. Hypervisor550 can then store the information in cache hierarchy table 556.
After the virtual cache topology is determined (and passed by management system 402 to hypervisor 550, in the case of a datacenter), it can be used by scheduler 552 when scheduling threads. In one embodiment, hypervisor 550 can set ideal logical processors for virtual processors in a way that honors the virtual cache topology. For example, and continuing the specific example from above, hypervisor 550 can set LP 506 as the ideal processor for VP 534 and LP 508 as the ideal processor for VP 536. Hypervisor 550 can then expose L2 cache between LP 506 and 508 as a virtual L3 cache. In this example embodiment as long as scheduler 552 can schedule VP 534 or VP 536 on any combination of logical processors in NUMA node 500 or NUMA node 502 the virtualized topology is honored. Moreover, if the physical cache being virtualized is an L2, guest operating system 532 may observe a performance increase.
In another example, hypervisor 550 can keep track of where virtual processors are executing and select a logical processor based on the exposed virtual topology and estimated cache miss cost associated with the available logical processors. Scheduler 552 can then determine the identities of the logical processors running other threads of virtual machine 530 and use this information to select a logical processor that honors the virtual cache topology and has the lowest estimated miss cost.
The following are a series of flowcharts depicting operational procedures. For ease of understanding, the flowcharts are organized such that the initial flowcharts present implementations via an overall "big picture" viewpoint and subsequent flowcharts provide further additions and/or details. Furthermore, one of skill in the art can appreciate that the operational procedure depicted by dashed lines are considered optional.
Turning now to FIG. 6, it illustrates an operational procedure including operations 600, 602, and 604. Operation 600 begins the operational process and operation 602 illustrates causing a list of idle logical processors to be generated in response to receiving a request to schedule a thread indicative of a virtual processor of a virtual machine. For example, and turning to FIG. 5, hypervisor 550 can be configured to instantiate and control virtual machine 530 and expose one or more virtual processors such as VP 534-VP540 to guest operating system 532. For example, a guest operating system can issue an instruction querying the virtual topology. This instruction can be intercepted by hypervisor 550 and virtualized. As shown by the dashed lines for virtual L3 cache, in an example embodiment virtual processors 534-540 may be single core virtual processors and the virtual L3 cache may not exist. Or put another way, in this example, a virtualized topology may not be exposed to guest operating system 532. In this example, guest operating system 532 may schedule a thread on virtual processor 534 and hypervisor 550 can receive a request to schedule virtual processor 534 on a logical processor. In response to receiving the request scheduler 552 can execute and generate a list of idle logical processors. In an example embodiment scheduler 552 could check an idle processor map and determine which processors in the system are idle.
Turning to operation 604, it shows causing the thread indicative of the virtual processor to be scheduled on a logical processor from the list that shares a level of cache with a seed logical processor. Continuing with the example above, scheduler 552 can execute and schedule the thread on a logical processor that shares a level of cache with a seed logical processor. For example, in this example embodiment scheduler 552 can attempt to schedule the thread on a logical processor that is close to a seed logical processor. In this example, scheduler 552 can increase performance of virtual machine 530 by increasing the chance that the thread will use data or instructions that are in the shared cache and the logical processor can run without having to fetch data or instructions from RAM or another NUMA node.
Continuing from the specific example above, scheduler 552 can determine that the seed for thread indicative of virtual processor 534 is logical processor 506. In the event that logical processor 506 is unavailable, scheduler 552 can then be configured to access cache hierarchy table 556 and determine which idle logical processors share cache with logical processor 506. Scheduler 552 can then be configured to select one of the logical processors that shares cache to run thread indicative of VP 534. For example, LP 508 and LP 514 may be idle. Scheduler 552 can access cache hierarchy table556 and determine LP 508 shares L2 and L3 with LP 506 and LP 506 shares L3 cache with LP 514. Scheduler 552 can then select one of the logical processors to run the thread.
Turning now to FIG. 7, it illustrates an alternative embodiment of the operational procedure of FIG. 6 including the additional operations 706-718. Operation 706 shows causing the thread indicative of the virtual processor to be scheduled on a logical processor that shares a level of cache with the seed logical processor in response to determining that a logical processor that last ran the thread indicative of the virtual processor is unavailable and a predetermined amount of time since the thread indicative of the virtual processor last executed has elapsed. For example, scheduler 552 may determine that the thread indicative of virtual processor 534 is associated with a latency sensitive workload. That is, the workload, e.g., the program executed by guest operating system 532, may need to be scheduled as soon as possible when the guest runs it on the virtual processor. For example, hypervisor 550 may obtain performance information from guest 532 indicating that its performance is sluggish or guest OS 532 is performing a lot of network based input/output work. In another embodiment, an administrator or policy could set threads from virtual machine 530 as latency sensitive. Regardless of how the thread was identified as latency sensitive, scheduler 552 can obtain information from thread table 560 when a request to schedule thread indicative of virtual processor 534 is received and determine how to schedule it.
In an example embodiment, scheduler 552 can immediately schedule the thread, or queue it depending on when the thread last ran. For example, if the thread recently ran, there is a chance that information it would use is still in cache. In the instance where the information is still in cache, the performance hit due to queuing may be less than the performance hit due to having a cache miss. Alternatively, if thread has not run recently, then the cache may be cold, i.e., may not have any useful information, and no performance benefits would be obtained by waiting any longer.
In this example, a predetermined threshold time can be used to determine that the thread should be run. For example, scheduler 552 can receive a request to schedule virtual processor 534. Scheduler 552 can run and access thread table 560to obtain information regarding virtual processor 534 such as information that describes that the thread is latency sensitive, a time that thread last ran, and the logical processor that last ran thread indicative of virtual processor 534. Scheduler 552can access an idle processor map and check to see what logical processors are available. In this specific example, the logical processor that last ran the thread, e.g., LP 506, may be unavailable. In this situation, scheduler 552 can compare the amount of time since virtual processor 534 last ran to a predetermined threshold and determine that the amount of time since it last ran is greater than the predetermined value. Schedule 552 can be scheduled to access cache hierarchy table556 and determine which available logical processors share cache with logical processor 506 and select one to run thread534.
Continuing with the description of FIG. 7, operation 708 shows causing the thread indicative of the virtual processor to be queued on a logical processor that last ran the thread indicative of the virtual processor in response to determining that the logical processor that last ran the thread indicative of the virtual processor is unavailable and a predetermined amount of time since the thread indicative of the virtual processor last executed not elapsed. Similar to operation 706, thread indicative of virtual processor 534 could be a latency sensitive thread. In this example, scheduler 552 can be configured to queue thread 534 on logical processor 506 in the instance that logical processor 506 is unavailable and the predetermined amount of time has not elapsed. In this example, a decision can be made that the savings do to obtaining cache hits will offset the fact that the latency sensitive thread is not executed as soon as possible. As stated above, the predetermined threshold can be set based on performance characteristics of the system and may be adjusted by an administrator or a policy.
Operation 710 of FIG. 7 shows causing the logical processor that last executed the thread indicative of the virtual processor to be set as the seed logical processor. For example, in an embodiment an administrator or a policy can be used by hypervisor 550 to set a seed logical processor for a virtual processor. In a specific example, the logical processor that last ran virtual processor 534 can be set as the seed. Thus, in this example embodiment, if thread 534 is moved from logical processor 506 to logical processor 508, the seed can be changed in thread table 560 to reflect that the seed is now logical processor 508. In this example, virtual machine 530 may be a single core virtual machine 530 and the only efficiency that can be obtained from cache hits is from configuring virtual processor 534 to share as many caches with the logical processor that last ran it.
Turning to operation 712, it shows causing an ideal logical processor to be set as the seed logical processor. For example, and turning to FIG. 5, an ideal logical processor can be set as the seed. In this example, the seed could be statically assigned at boot based on a policy or by an administrator. In this example, the seed can remain constant even if threads indicative of virtual processors are moved by scheduler 552. For example, virtual machine 530 can be instantiated. A policy could be read by hypervisor 550 that directs it to set ideal processors for virtual processors 534-540. In response, hypervisor 550 can assign logical processor 506 as the ideal for virtual processor 534, logical processor 508 as the ideal for virtual processor 536 and so on and so forth. This information can then be recorded in thread table 560. In the event that virtual processor 534 is moved the next time it runs scheduler 552 can be configured to access thread table 560; determine that LP 506 is set as an ideal LP; and check to see if LP 506 is free. In this example, if LP 506 is free it is scheduled thereon regardless of the identity of the last LP that ran VP 534. If it unavailable, scheduler 552 attempts to locate it as close as possible to the ideal LP.
Turning to operation 714, it shows causing the thread indicative of the virtual processor to be scheduled on a logical processor from the list that shares the highest level of cache with the seed logical processor. For example, in an example scheduler 552 can be configured to attempt to collocate virtual processors such that they share the highest level of cache. In this example, guest 532 has the best chance of seeing a performance increase due to cache hits. As described above, each logical processor can have arrays associated therewith stored in cache hierarchy table 556. In response to receiving a request to schedule a thread indicative of a VP, such as VP 534, scheduler 552 can determine the seed for VP 534 and access cache hierarchy table 556 to determine the available LP that shares the highest level of cache with the seed. Scheduler 552 can then schedule the thread on an available LP that shares the highest level of cache with the seed.
Turning to operation 716, it shows causing the list of idle logical processors to be generated from a list of logical processors in a specific NUMA node. Hypervisor 550 can be configured to maintain idle processor maps for each NUMA node in the computer system. In this example, each virtual processor could be assigned an ideal NUMA node when virtual machine 530is started and this information could be stored in thread table 560. When scheduler 552 runs it can determine that a thread has been assigned an ideal NUMA node and scheduler 552 can generate the list of idle processors from an idle processor map associated with the ideal NUMA node. In this way the initial set of possible logical processor candidates is reduced. In a specific example, NUMA node 500 could be the ideal NUMA node for thread indicative of virtual processor 534. Scheduler552 can obtain this information from thread table 560; access idle processor map 554; and generate a list of idle processors in NUMA node 500.
Continuing with the description of FIG. 7, operation 718 shows causing a virtual cache topology to be exposed to a guest operating system, wherein the virtual cache topology is based on physical cache topologies of a plurality of computer systems. For example, and turning to FIG. 5, hypervisor 550 can obtain configuration information that describes how to generate a virtual cache topology for virtual machine 530. In an embodiment, hypervisor 550 can generate the information or, in a datacenter embodiment, it can receive the configuration information from, for example, management system 402 ofFIG. 4. The configuration information can describe a virtual cache topology that can be exposed to guest operating system532 when it boots. Guest operating system 532 can then detect the topology and configure it's scheduler to depend on it. For example, guest operating system 532 can query the hardware to determine the topology. Hypervisor 550 can intercept the query and respond with virtualized information that describes the virtual cache topology. In this example, the virtual cache topology can be independent from the physical topology of the host computers system so that guest operating system 532 can be easily migrated to any computer system in datacenter 400.
Turning now to FIG. 8, it illustrate an alternative embodiment of the operational procedure depicted in FIG. 7. FIG. 8includes a refinement 820 of operation 718, wherein the virtual cache topology information includes a number of virtual processors sharing a virtual cache. For example, hypervisor 500 or management system 402 of datacenter 400 can be configured to generate the virtual cache topology exposed to guest operating system 532. The virtual cache topology can include a calculated number of virtual processors that share a virtual cache. In an example, the number of processors can be determined by calculating the greatest common divisor of logical processors that share a lowest level of cache for each NUMA node in datacenter 400. For example, each computer system can have a topology the same as the physical topology described in FIG. 5 and management system 402 can be configured to determine the lowest level of cache in each NUMA node, e.g., L3 cache in this example, and determine the number of logical processors in each NUMA node that shares this level of cache, i.e., 6 in NUMA node 500 and 4 in NUMA node 502. Management system 402 can then determine that the greatest common divisor between 6 and 4 is 2. This value can be set as the number of virtual processors that share a level of cache in the virtual cache topology.
In another example, the number of virtual processors that share a level of cache in the virtual cache topology can be calculated using a different technique. For example, management system 402 can determine the number of logical processors that share a highest level of cache in each NUMA node. Management system 402 can then set the smallest number of logical processors as the number of virtual processors that share a level of cache in the virtual cache topology. For example, management 402 can receive information that describes that L2 is the highest cache shared by logical processors 506-512, L2 is the highest cache shared between logical processors 514-516, and L3 is the highest level of cache shared between logical processors 518-524. Management system 402 can then determine that 4, 2, and 4, logical processors share respective highest levels of cache in the computer systems in, for example datacenter 400. In this example embodiment management system 402 can select the smallest number (2) and set it as the number of virtual processors that share a level of cache in the virtual cache topology.
Turning now to FIG. 9, shown is refinement 922 of operation 820, wherein the virtual cache topology information includes a cache level for the virtual cache, wherein the cache level is based on the lowest level of cache shared between a number of logical processors. For example, after the number of virtual processors for the virtual cache topology is determined, the type of virtual cache that is shared can be determined. In an example embodiment the lowest type of cache shared by a number of logical processors equal to or greater to the determined number of virtual processors can be used as the virtual cache.
For example, are referring to FIG. 5, management system 402 can be configured to receive information describing that NUMA node 500 includes an L2 cache that is shared between 4 logical processors, an L2 cache shared between 2 logical processors, and an L3 cache shared between 6 logical processors. Management system 402 can also receive information that describes that NUMA node 502 includes an L3 cache shared between 4 logical processors. In this example, management system 402 can determine that NUMA node 500 can support an L2 and L3 cache shared between a number of logical processors equal or greater than the number of virtual processors set for the virtual cache topology. Management system 402 can also determine that NUMA node 502 can support an L3 cache shared between a number of logical processors equal or greater than the number of virtual processors set for the virtual cache topology. Management system402 can select L3 as the cache to expose in virtual cache topology because it is the lowest cache that can be honored by each NUMA node.
Turning now to FIG. 10, it illustrates an operational procedure including operations 1000, 1002, 1004, 1006, and 1008. Operation 1000 begins the operational procedure and operation 1002 shows exposing a plurality of single core virtual processors to a virtual machine. For example, and turning to FIG. 5, a computer system can execute instructions indicative of hypervisor 550 and can load instructions operable to instantiate virtual machine 530. Hypervisor 550 can set up virtual machine 530 to include a plurality of virtual processors such as virtual processors 534-540. In this example, the virtual processors can be single core VPs. Put another way, the virtual processors 534-540 may not share caches. Guest operating system 532 can boot and detect the single cored virtual processors by querying the virtual topology. Hypervisor550 can intercept the query and return a virtualized topology including a plurality of single core virtual processors.
Continuing with the description of FIG. 10, operation 1004 shows generating a list of idle logical processors in response to receiving a request to execute a thread indicative of a single core virtual processor. For example, an executing instance of hypervisor 550 can be set to generate a list of idle logical processors in the event that it receives a request to schedule a thread indicative of a virtual processor such as virtual processor 540. For example, executable instructions of scheduler 552can be loaded into memory that set up idle processor maps for the logical processors in a computer system and hypervisorcan be configured to run scheduler 552, which can generate a list of idle logical processors, in response to receiving a thread from a guest such as guest operating system 532.
Turning now to operation 1006, it shows identifying logical processors currently executing threads indicative of single core virtual processors of the virtual machine. Continuing with the example, in response to a request to run a thread indicative of a virtual processor, such as VP 540, hypervisor 550 can determine where threads indicative of the virtual processors of the VM are currently executing. For example, each time a logical processor runs it can update thread table 560 with information that identifies which virtual processor it is running. When hypervisor 550 runs, it can check thread table 560 and see what logical processors are currently running virtual processors for the virtual machine. For example, virtual processor 534 can be executing on logical processor 514, virtual processor 536 can be executing on LP 516, and virtual processor 538 can be executing on virtual processor 512.
Turning now to operation 1008, it shows scheduling the thread indicative of the virtual processor on a logical processor from the list that shares a cache with a maximum number of logical processors currently executing the threads indicative of the single core virtual processors of the virtual machine. For example, scheduler 552 can determine which idle logical processor shares a cache the maximum number of logical processors currently running threads indicative of the other VPs in the virtual machine. For example, scheduler 552 can access cache hierarchy table 556, which can include an array of bitmaps for each logical processor, and determine which of the available processors shares a cache with the max number of LPs. Continuing with the example from above, scheduler 552 can schedule thread indicative of virtual processor 540 on logical processor506 since logical processor 506 shares cache with the maximum number of currently executing virtual processors.
Turning now to FIG. 11, it shows an alternative embodiment of the operational procedure of FIG. 10 including operations1110 and 1112. Operation 1110 shows generating the list of idle logical processors from a list of logical processors in a non-uniform memory architecture (NUMA) node, wherein each NUMA node in a computer system is associated with a unique list of logical processors in the NUMA node. For example, scheduler 552 can be configured to schedule the thread on a logical processor that shares a highest level of cache with a maximum amount of virtual processors currently running. For example, in an embodiment scheduler 552 may determine that there are multiple available logical processors that share cache with a maximum number of logical processors. In this example, scheduler 552 can be configured to select the logical processor that shares the highest cache with the most logical processors. For example, in an embodiment logical processors 508-514 may be running 4 virtual processors of a virtual machine including 5 virtual processors. Scheduler 552may determine that LP 506 and LP 516 are available and each share L3 cache with the logical processors currently running virtual processors of the virtual machine. In this example scheduler 552 can determine that logical processor 506 shares L2 cache with 3 of the 4 logical processors and LP 516 shares L2 cache with 1 logical processor. In this example scheduler552 can select logical processor 506.
Continuing with the description of FIG. 11, operation 1112 shows scheduling the thread indicative of the virtual processor on the logical processor in response to determining that a logical processor that last ran the thread indicative of the virtual processor is unavailable and a predetermined amount of time since the thread indicative of the single core virtual processor last executed has elapsed. For example, scheduler 552 may determine that the thread is associated with a latency sensitive workload. That is, the workload, e.g., the programs executed by guest operating system 532, may need to be scheduled as soon as possible when it is received by scheduler 552. In this example, if a predetermined amount of time since the VP last ran has elapsed, schedule 552 can be scheduled to access cache hierarchy table 556 and determine which available logical processors share cache with, for example, the logical processor that last ran it or one that shares a cache with a maximum number of logical processors currently executing virtual processors of the virtual machine.
Turning now to FIG. 12, it illustrates a operational procedure including operations 1200, 1202, 1204, and 1206. Operation1200 begins the procedure and operation 1202 shows causing a thread indicative of a virtual processor of a virtual machine to be assigned a distinct logical processor to execute thereon. In an embodiment, hypervisor 550 can assign each virtual processor of a virtual machine a distinct logical processor. In this example, when a request to schedule the virtual processor is received, hypervisor 550 can attempt to schedule the virtual processor on the assigned logical processor. For example, thread table 560 can store information that identifies the assigned logical processor. Scheduler 552 can check thread table560 when it receives a request to schedule a thread.
Continuing with the description of FIG. 12, operation 1204 shows causing a list of idle logical processors to be generated in response to receiving a request to execute the thread indicative of a virtual processor. For example, an executing instance of hypervisor 550 can be set to generate a list of idle logical processors in the event that it receives a request to schedule a thread indicative of a virtual processor such as virtual processor 540. For example, executable instructions of scheduler 552can be loaded into memory that set up idle processor maps for the logical processors in a computer system and hypervisor can be configured to run scheduler 552, which can generate a list of idle logical processors, in response to receiving a thread from a guest such as guest operating system 532.
Turning back again to FIG. 12, operation 1206 shows causing the thread indicative of the virtual processor to be scheduled on a logical processor that shares a level of cache with the distinct logical processor assigned to execute the thread indicative of the virtual processor. For example, scheduler 552 can determine which idle logical processors share a cache with the assigned logical processor and select one. For example, scheduler 552 can access cache hierarchy table 556, which can include an array of bitmaps for each logical processor, and determine which of the available processors shares a cache with assigned logical processor.
Referring now to FIG. 13, it illustrate an alternative embodiment of the operational procedure illustrated in FIG. 12 including the additional operations 1308, 1310, 1312, 1314, 1316, and 1318. Operation 1308 shows causing the logical processor that shares the level of cache with the distinct logical processor to be selected in response to determining that the distinct logical processor is unavailable. For example, scheduler 552 can be configured to attempt to schedule thread indicative of a virtual processor on the assigned logical processor. In the event that the processor is unavailable, it can schedule the thread indicative of the virtual processor on a logical processor that shares a level of cache with a logical processor assigned to execute the thread indicative of the virtual processor.
Operation 1310 shows causing the thread indicative of the virtual processor to be scheduled in response to determining that a predetermined amount of time since the thread indicative of the virtual processor last executed has elapsed. For example, in an embodiment scheduler 552 can be configured to locate a logical processor to run a latency sensitive workload. That is, the workload, e.g., the programs executed by guest operating system 532, may need to be scheduled as soon as possible when it is received by scheduler 552. In this example, if a predetermined amount of time since the VP last ran has elapsed, schedule 552 can be scheduled to access cache hierarchy table 556 and determine which available logical processors share cache with, for example, the assigned logical processor.
Operation 1312 shows causing the thread indicative of the virtual processor to be queued on a logical processor that last ran the thread indicative of the virtual processor in response to determining that a logical processor that last ran the thread indicative of the virtual processor is unavailable and a predetermined amount of time since the thread indicative of the virtual processor last executed not elapsed. In an embodiment, thread indicative of virtual processor 534 could be a latency sensitive thread. In this example, scheduler 552 can include instructions for queuing the thread in the instance that logical processor 506 is unavailable and the predetermined amount of time has not elapsed. In this example, a decision can be made that the savings do to having cache hits will offset the fact that the latency sensitive thread is not executed as soon as possible. As stated above, the predetermined threshold can be set based on performance characteristics of the system and may be adjusted by an administrator or a policy.
Operation 1314 shows causing a list of idle logical processors to be maintained for each non-uniform memory architecture (NUMA) node in the computer system. For example, hypervisor 550 can be configured to maintain idle processor maps for each NUMA node in the computer system. In this example, the NUMA node that includes the assigned processors can be set as the node that scheduler 552 first checks in response to receiving a request to schedule a thread. When scheduler552 runs, it can generate the list of idle processors from an idle processor map associated with NUMA node. In this way the initial set of possible logical processor candidates is reduced without having to check a bitmap listing every logical processor in the computer system.
Operation 1316 shows causing the thread indicative of the virtual processor to be scheduled on a logical processor that shares a highest level of cache with the logical processor assigned to execute the thread indicative of the virtual processor. For example, scheduler 552 can be configured to attempt to collocate virtual processors such that they share the highest level of cache. In this example, guest 532 has the best chance of seeing a performance increase due to cache hits. As described above, each logical processor can have arrays associated therewith stored in cache hierarchy table 556. In response to receiving a request to schedule a thread indicative of a VP, such as VP 534, scheduler 552 can determine the seed for VP 534 and access cache hierarchy table 556 to determine the available LP that shares the highest level of cache with the assigned logical processor. Scheduler 552 can then schedule the thread on an available LP that shares the highest level of cache with the assigned logical processor.
Operation 1318 shows causing a plurality of virtual processors interconnected by a virtual cache to be exposed to a guest operating system. For example, and turning to FIG. 5, hypervisor 550 can obtain configuration information that describes how to generate a virtual cache topology for virtual machine 530. In an embodiment, hypervisor 550 can generate the information or, in a datacenter embodiment, it can receive the configuration information from, for example, management system 402 of FIG. 4. The configuration information can describe a virtual cache topology that can be exposed to guest operating system 532 when it boots. Guest operating system 532 can then detect the topology and configure it's scheduler to depend on it. For example, guest operating system 532 can query the virtual processors to determine the topology. Hypervisor 550 can intercept the query and respond with topology information that describes the virtual cache topology. In this example, the virtual cache topology can be independent from the physical topology of the host computers system so that guest operating system 532 can be easily migrated to any computer system in datacenter 400.