Hardware throughput saturation detection

#This application is related to U.S. patent application Ser. No. 12/242,615 entitled “TEMPORAL BATCHING OF I/O JOBS” filed Sep. 30, 2008 and incorporated by reference in its entirety; U.S. application Ser. No. 12/242,624 entitled “BALANCING USAGE OF HARDWARE DEVICES AMONG CLIENTS” filed Sep. 30, 2008 and incorporated by reference in its entirety.

#Virtualization provides techniques for consolidating physical machines. That is, multiple virtual machines can be executed by a single physical machine. When servers are consolidated, a problem exists in how the virtual machines access the physical hardware. For example, if 5 virtual machines are effectuated by software instructions each one of them may attempt to access a physical hardware device such as a storage device, network adaptor, etc. The hardware device many not be able to efficiently support this many requesters and one or more of the virtual machines may experience resource starvation, e.g., the instance where the virtual machine is denied resources and its requests experience high latency. This is due to the fact that hardware devices are not configured to process information that identifies which IO jobs are from which virtual machine. The hardware device of course does not select IO jobs to complete in an arbitrary order, it selects IO jobs to maximize throughput and because of this certain IO jobs may sit in the device's buffer for an unacceptable length of time. For example, a driver for a hardware device such as a storage device may complete 200 IO jobs from a first virtual machine before completing 8 IO jobs from a second virtual machine because completing the 200 IO jobs may allow the hardware device to achieve higher throughput than if it completed the 8 IO jobs. One solution to eliminate resource starvation would be to limit the IO jobs that the driver can select buy sending IO jobs to the hardware one at a time. This technique implemented naively would severely impact throughput. That is, by hand picking each IO job the hardware device would not be able to reach its throughput potential. Thus, techniques for balancing throughput vs. resource starvation are desirable.

#An example embodiment of the present disclosure describes a method. In this example, the method includes, but is not limited to estimating time cost values for a plurality of IO jobs from a completion sequence, the time cost equal to an estimated amount of time a hardware device will take to process a given IO job; determining a target latency value for the hardware device; determining an in-flight time cost value, the in-flight time cost value indicative of the time cost for IO jobs that are being processed by the hardware device; and sending an amount of IO jobs to the hardware device, the amount having a combined time cost value operable to increase the in-flight time cost to at least the target latency value. In addition to the foregoing, other aspects are described in the claims, drawings, and text forming a part of the present disclosure.

#FIG. 1 depicts an example computer system wherein aspects of the present disclosure can be implemented.

#FIG. 2 depicts an operational environment for practicing aspects of the present disclosure.

#FIG. 3 depicts an operational environment for practicing aspects of the present disclosure.

#Embodiments of the present disclosure may execute on one or more computers. FIG. 1 and the following discussion is intended to provide a brief general description of a suitable computing environment in which the disclosure may be implemented. One skilled in the art can appreciate that some or all of the components of the computer system of FIG. 1 can be used to effectuate computer 200 of FIG. 2 and the computer 200 of FIG. 3.

#The term circuitry used through the disclosure can include specialized hardware components such as hardware interrupt controllers, hard drives, network adaptors, graphics processors, and audio codecs for example. In the same or other embodiments circuitry can include microprocessors configured to perform function(s) by firmware or by set switches. In the same or other example embodiments circuitry can include one or more logical processors, e.g., one or more cores of a multi-core general processing unit. The logical processor(s) in this example can be configured by software instructions embodying logic operable to perform function(s) that are loaded from memory, e.g., RAM, ROM, firmware, and/or virtual memory. In example embodiments where circuitry includes a combination of hardware and software an implementer may write source code embodying logic that is subsequently compiled into machine readable code that can be processed by the logical processor. Since one skilled in the art can appreciate that the state of the art has evolved to a point where there is little difference between hardware, software, or a combination of hardware/software, the selection of hardware versus software to effectuate specific functions is a design choice left to an implementer. More specifically, one of skill in the art can appreciate that a software process can be transformed into an equivalent hardware structure, and a hardware structure can itself be transformed into an equivalent software process. Thus, the selection of a hardware implementation versus a software implementation is one of design choice and left to the implementer.

#Referring now to FIG. 1, an exemplary general purpose computing system is depicted. The general purpose computing system can include a conventional computer 20 or the like, including a general purpose processing unit 21 that can include one or more logical processors, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21. The system bus 23 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. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system 26 (BIOS), containing the basic routines that help to transfer information between elements within the computer 20, such as during start up, is stored in ROM 24. The computer 20 may further include a hard disk drive 27 for reading from and writing to a hard disk, not shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to a removable optical disk 31 such as a CD ROM or other optical media. In some example embodiments computer executable instructions embodying aspects of the present disclosure may be stored in ROM 24, hard disk (not shown), RAM 25, removable magnetic disk 29, optical disk 31, and/or a cache of general purpose processing unit 21. The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively. The drives and their associated computer readable media provide non volatile storage of computer readable instructions, data structures, program modules and other data for the computer 20. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 29 and a removable optical disk 31, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs) and the like may also be used in the exemplary operating environment.