Method and apparatus for selectively prefetching based on resource availability

One embodiment of the present invention provides a system which facilitates selective prefetching based on resource availability. During operation, the system executes instructions in a processor. While executing the instructions, the system monitors the availability of one or more system resources and dynamically adjusts an availability indicator for each system resource based on the current availability of the system resource. Upon encountering a prefetch instruction which involves the system resource, the system checks the availability indicator. If the availability indicator indicates that the system resource is not sufficiently available, the system terminates the execution of the prefetch instruction, whereby terminating execution prevents prefetch instructions from overwhelming the system resource.

BACKGROUND

1. Field of the Invention

The present invention relates to techniques for improving computer system performance. More specifically, the present invention relates to a method and apparatus for selectively prefetching based on resource availability.

2. Related Art

Hardware prefetching (“automatic prefetching”) and software prefetching (“explicit prefetching”) are two well known techniques for enhancing the performance of the caches in computer systems (where “caches” include hardware structures such as data caches, instruction caches and Translation Lookaside Buffers (TLBs)).

In a computer system that uses hardware prefetching, system hardware monitors runtime data access patterns and uses the access patterns to make predictions about future loads and stores. Based on these predictions, the system hardware issues automatic prefetch requests in anticipation of accesses.

In a computer system that uses software prefetching, software applications are tuned by inserting explicit prefetch instructions into the executable code in order to minimize the number of cache misses by subsequent load and store operations. These prefetch instructions can be placed so that they complement the automatic (hardware) prefetch behavior of the processor on which the software is executing.

Using these two techniques should result in significant performance improvement. In practice, however, the techniques have several limitations which significantly reduce the expected performance improvement. In fact, these limitations are so significant that they have impeded the widespread adoption of these techniques.

One such limitation is “processor implementation sensitivity,” which occurs because the use of prefetches is highly dependent on the implementation details of the processor on which a software application is running. For example, the sizes of the caches, the number of ways in each cache, the load-to-use latency of a main memory access, and the clock frequency of the processor are processor implementation details that can affect the use of prefetches.

Processor implementation sensitivity is apparent in many commercially available software applications. Because software designers typically deliver only a single executable binary which is designed to be executed on a variety of different processors from the same processor family, the prefetch requests are not optimized for each possible processor implementation. The suppliers (1) choose the most popular variant within the processor family and optimize for that variant, or (2) deliver a binary that is suboptimal for any particular processor variant, but maximizes the average performance gain across the whole family.

A second limitation is “workload insensitivity,” which occurs in computer systems where more than one virtual or physical processor is sending prefetch requests to a shared cache. For a single application (or a single execution thread), aggressive prefetching can produce considerable performance gains—because the cache is dedicated to the single application. Unfortunately, in a multi-application system, two or more executables time-share a processor and that processor's caches. In this case, aggressive prefetching by one application can displace the data in the shared cache that another application is actively using. In fact, multiple executables, each performing self-interested prefetching, can cause so much interference in the cache that the resulting performance is significantly worse than if each executable was run sequentially—a phenomenon known as “thrashing in the cache.”

A third limitation is “shared resource insensitivity,” which occurs because modern processors contain multiple processor cores which share system resources in a complex arrangement. Caches are one example of a system resource that is particularly vulnerable to shared resource complications. Because of the technical difficulties involved with one processor assessing the cache footprints taken up by the other processor cores, each processor core may operate without knowing how much space is available in the cache. Therefore, the processor cores typically restrict the use of aggressive prefetching or risk overloading and thrashing in the cache.

Although cache performance is affected by shared resource insensitivity, caches are not the only system resource affected by this condition. The processor cores also share other resources, such as the system bus. Aggressive speculative prefetching may load these system resources with counterproductive or unnecessary work, hampering the efficient operation of the computer system.

A fourth limitation is “competitive prefetching interference,” which occurs in systems that combine hardware and software prefetching. In pathological cases, hardware and software prefetching can actually interfere with each other. Competitive prefetching interference occurs when the software issues prefetch requests which hardware has already issued, or when the false miss rate of the hardware and software prefetching combined exceeds the threshold at which actively used cache lines begin to be evicted, thereby causing cache thrashing.

Hence, what is needed is a method and apparatus which allows prefetching to be used aggressively without causing system-level performance degradation.

SUMMARY

One embodiment of the present invention provides a system which facilitates selective prefetching based on resource availability. During operation, the system executes instructions in a processor. While executing the instructions, the system monitors the availability of one or more system resources and dynamically adjusts an availability indicator, such as a register, for each system resource based on the current availability of the system resource. Upon encountering a prefetch instruction which involves the system resource, the system checks the availability indicator. If the availability indicator indicates that the system resource is not sufficiently available, the system terminates the execution of the prefetch instruction, whereby terminating execution prevents prefetch instructions from overwhelming the system resource.

In a variation of this embodiment, monitoring the availability of a system resource involves monitoring the use of the system resource by two or more virtual or physical processors.

In a variation of this embodiment, the prefetch instruction includes a conditional field which indicates at least one condition under which the prefetch instruction is executed despite the system resource not being sufficiently available.

In a variation of this embodiment, the system performs a just-in-time compilation to set the conditional field of the prefetch instruction at runtime. The term “just-in-time compilation (JIT), also known as dynamic translation, refers to a technique for improving the performance of bytecode-compiled programming systems, by translating bytecode into native machine code at runtime” (see Wikopedia). Just-in-time compilation is commonly performed in JAVA™ programming environments.

In a variation of this embodiment, monitoring the availability of a system resource involves monitoring (1) the availability of cache lines in a cache; (2) the availability of entries in a translation-lookaside-buffer (TLB); (3) the availability of bandwidth on a system bus; (4) the local work level of a component in the computer system; or (5) the global work level of the computer system.

In a further variation, monitoring the availability of the system resource involves using at least one current system activity level to predict when the system resource will become unavailable in the future.

In a variation of this embodiment, adjusting an availability indicator involves setting a least-significant bit of a shift register each time that an instruction uses a monitored system resource, wherein the shift register is shifted by one position each usage interval for the monitored system resource.

In a further variation, checking the availability indicator involves checking (1) the current value of the shift register; (2) a valid indicator associated with the system resource; or (3) a value of a hardware or software performance counter associated with a monitored system resource.

DETAILED DESCRIPTION

The data structures and code described in this detailed description are typically stored on a computer readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital versatile discs or digital video discs).

System

FIG. 1illustrates a computer system in accordance with an embodiment of the present invention. Computer system116includes multiple processors100-102, switch104, L2 cache106, and main memory110. Each processor100-102in turn includes an L1 cache120-122. L1 caches120-122, L2 cache106, and main memory110collectively form the memory system that holds the instructions and data necessary for the operation of computer system116. Switch104manages the flow of prefetch requests (which prefetch data values from main memory110to L2 cache106). Computer system116uses local bus112and system bus114to transfer data between the system resources in computer system116.

Monitoring mechanism108monitors the current “availability” of computer system116resources. For example, monitoring mechanism108may monitor the availability of cache lines within a cache, the overall activity level in a cache, the availability of entries in a TLB, or the available bandwidth on system bus114.

Monitoring mechanism108maintains an “availability indicator” corresponding to each monitored system resource. When the availability of a system resource falls below the amount required to effectively service a prefetch request, monitoring mechanism108asserts the corresponding indicator.

During the operation of computer system116, switch104intercepts and holds the prefetch requests generated by processors100-102. Before releasing the prefetch request to main memory110, switch104checks the availability indicators corresponding to the system resources required to service the prefetch request. If an availability indicator is asserted for a system resource required by the prefetch request, switch104terminates the prefetch. Terminating the prefetch in this way helps to prevent the processors100-102from overwhelming the system resource with prefetch requests.

In one embodiment of the present invention, monitoring mechanism108uses a shift buffer as an availability indicator. For example, monitoring mechanism108can set the least significant bit of a shift buffer every time a line is allocated in the cache, while continually bit-shifting the shift buffer at a constant rate (e.g., once per clock cycle). At any point in time, the cache is defined as IDLE when all the bits in the shift buffer are zero. Alternatively, the cache is defined as NOT BUSY when some of the bits in the shift buffer are zero.

In another embodiment, monitoring mechanism108uses the current value in a performance counter corresponding to a system resource as an availability indicator.

In yet another embodiment, monitoring mechanism108uses valid bits corresponding to the to-be-prefetched cache line as an availability indicator. When a processor100sends a prefetch, monitoring mechanism108examines the valid bits at the index in the cache computed from the to-be-prefetched cache line. If all of the valid bits are set (i.e., every “way” at that index is in use), the cache is BUSY. If at least one of the valid bits is zero, the cache is defined as NOT BUSY. If all of the valid bits are zero, the cache is defined as IDLE.

Monitoring mechanism108may also monitor the current activity levels of selected areas of computer system116and may use those activity levels to make predictions about the future availability of system resources. For example, monitoring mechanism108can monitor activities in a processor100to predict when local bus112may become busy.

Note that processors100-102may be separate physical processors or may be virtual processors within a single CMT processor. Furthermore, switch104and monitoring mechanism108are described as hardware structures, but in an alternative embodiment switch104and monitoring mechanism108can be implemented in software.

The Extended Prefetch Instruction

In one embodiment of the present invention, the prefetch instruction is extended to include a conditional field which prevents computer system116(seeFIG. 1) from terminating the prefetch despite the assertion of the system resource indicators. This field allows a programmer to force the execution of the prefetch in situations where the prefetched data is very likely to be used by a subsequent instruction. For example, the set of available prefetch instructions can include instructions such as:

PREFETCH-FOR-READ-IF-SYSTEM-BUS-IDLE; and

In an alternative embodiment monitoring mechanism108is designed to work with “legacy code” (code without the extended prefetch instructions). For this embodiment, monitoring mechanism108automatically permits legacy prefetch instructions to execute, while monitoring the execution of the extended prefetch instructions.

In one embodiment of the present invention, monitoring mechanism108also provides a series of configuration mechanisms which control the response of monitoring mechanism108when receiving a prefetch, whether in a system that supports extended prefetch instructions or not. For example, configuration mechanisms can be provided that allow a user to control the level of at which hardware prefetching is permitted and that allow the user to control what system resources is available before switch104allows the prefetch to continue.

Prefetching Process

FIG. 2presents a flow chart illustrating a prefetching process in accordance with an embodiment of the present invention. The process starts with a processor100(seeFIG. 1) issuing instructions while a monitoring mechanism108monitors the “availability” of a group of system resources (step200). During this process, monitoring mechanism108dynamically adjusts an availability indicator based on the current availability of each system resource (step202).

Processor100then determines if the issued instruction is a conditional prefetch instruction (step204). If the issued instruction is not a conditional prefetch instruction, processor100executes the instruction (step206) and returns to step200to issue the next instruction in program order.

One embodiment of the present invention uses prefetch instructions which are extended to include a conditional field. For this embodiment, the programmer (or compiler) uses the conditional field to indicate when the prefetch instruction should be sent to main memory110despite the fact that one or more system resources required by the prefetch instruction are currently unavailable—thereby “forcing” the prefetch. In an alternative embodiment, the computer system operates with “legacy” prefetch instructions (which do not include the conditional field). For this embodiment, monitoring mechanism108automatically permits the execution of legacy prefetch instructions (step206), while monitoring the execution of conditional prefetch instructions.

If the instruction is a conditional prefetch instruction, processor100executes the instruction, thereby sending a prefetch request to main memory110. Before the prefetch request reaches main memory110, the prefetch request passes into switch104. Switch104holds the prefetch request while determining if the extended field of prefetch instruction had contained a value that met the necessary condition to force the prefetch request to be sent to main memory (despite the potential unavailability of one or more system resources required by the prefetch request) (step208). If the forcing condition is met, switch104releases the prefetch request to main memory110(step210). Processor100then returns to step200to issue the next instruction in program order.

If the forcing condition is not met, switch104queries monitoring mechanism108to determine if the availability indicator is asserted for any system resource required by the prefetch instruction (step212). An availability indicator is asserted if the system resource is unavailable (too busy) to complete the prefetch request. If monitoring mechanism108reports that none of the availability indicators is asserted for system resources required by the prefetch request, switch104releases the prefetch request to main memory110(step210). Processor100then returns to step200to issue the next instruction in program order.

If one or more of the required availability indicators are asserted, switch104terminates the execution of the prefetch request (step214). Processor100then returns to step200to issue the next instruction in program order.