Patent Abstract:
A performance monitoring technique provides task-switch immune operation without requiring storage and retrieval of the performance monitor state when a task switch occurs. When a hypervisor signals that a task is being resumed, it provides an indication, which starts a delay timer. The delay timer is resettable in case a predetermined time period has not elapsed when the next task switch occurs. After the delay timer expires, analysis of the performance monitor measurements is resumed, which prevents an initial state or a state remaining from a previous task from corrupting the performance monitoring results. The performance monitor may be or include an execution trace unit that collects taken branches in a current trace and may use branch prediction success to determine whether to collect a predicted and taken branch instruction in a current trace or to start a new segment when the branch resolves in a non-predicted direction.

Full Description:
BACKGROUND 
       [0001]    1. Field of the Invention 
         [0002]    The present invention is related to computer systems in which performance is measured using hardware measurement circuits, and in particular to techniques for maintaining performance monitoring measurements across program execution cycles. 
         [0003]    2. Description of Related Art 
         [0004]    In computer systems, performance can be improved by monitoring the performance of the computer system while executing various programs, for example, the number of instructions executed or the total time elapsed while performing a task is a benchmark indication of the efficiency of the computer system at performing the task. By observing characteristics of program execution, in particular, by observing characteristics of “hot spots”, i.e., portions of a program that are executed most frequently, the program can be optimized, either off-line or on-the-fly, using the result of the performance measurements. 
         [0005]    However, when a task is off-loaded, when the present execution of a program is terminated, to be resumed at a later time and the program is unloaded from memory, the state of the performance monitoring hardware is typically lost, making it difficult to monitor performance of tasks that are executed intermittently. In some cases the performance monitoring state may not be accessible so that the state cannot be stored and retrieved when the task is off-loaded. 
         [0006]    A particular performance monitoring technique, as disclosed in U.S. patent application Ser. No. 12/828,697 filed on Jul. 10, 2010 entitled “HARDWARE ASSIST FOR OPTIMIZING CODE DURING PROCESSING”, having common inventors with the present U.S. patent application, and which is incorporated herein by reference, identifies execution paths, i.e., sequences of program instructions, in which all of the branch instructions resolve to particular directions, so that the most frequently executed paths, corresponding to the hot spots described above, are given the most effort and resources for program optimization. Rather than collecting the entire state of the branch history for each execution path in order to identify which path is currently being taken by a program, a simplified technique uses branch prediction data to assume a particular execution path is taken if all predictions are correct. Branch prediction state information is also typically not retained, and may not be accessible for storage and retrieval. 
       BRIEF SUMMARY 
       [0007]    The invention is embodied in a method, a computer system, a processor core, and a computer program product, in which performance monitoring information is not retained when a task is off-loaded and when a task is loaded for execution, performance monitoring analysis is postponed until sufficient performance monitoring has been performed to ensure accuracy of the results. 
         [0008]    The performance monitoring output or analysis may be delayed for a predetermined time period or instruction cycles, and may be triggered by a computer program such as a hypervisor, indicating that the task has been loaded and the delay should be started. After the delay has expired, the performance monitoring results may be analyzed. 
         [0009]    The performance monitoring may be a program execution branch analysis that determines frequently executed execution paths by using successful branch predictions to provide an indication that a particular execution path is being taken and the application of the technique may be postponed until the branch history information for the new task execution session has been updated and the effects of state information retained from a previous session or generated as an initialized state (e.g., reset state) has been attenuated. 
         [0010]    The foregoing and other objectives, features, and advantages of the invention will be apparent from the following, more particular, description of the preferred embodiment of the invention, as illustrated in the accompanying drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING 
         [0011]    The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives, and advantages thereof, will best be understood by reference to the following detailed description of the invention when read in conjunction with the accompanying Figures, wherein like reference numerals indicate like components, and: 
           [0012]      FIG. 1  is a block diagram illustrating a computer system including in which techniques according to an embodiment of the present invention are practiced. 
           [0013]      FIG. 2  is a block diagram illustrating details of processor cores  20 A- 20 B in the computer system of  FIG. 1 . 
           [0014]      FIG. 3  is a pictorial diagram showing details of performance monitoring unit  40  of  FIG. 2  in accordance with an embodiment of the present invention. 
           [0015]      FIG. 4  is a flowchart of a method of performance monitoring within a processor core in accordance with an embodiment of the present invention. 
           [0016]      FIG. 5  is an execution diagram showing exemplary branching patterns within a computer system having processor cores in accordance with an embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0017]    The present invention encompasses techniques for program performance monitoring in computer systems in which program operation may be interrupted by context and/or task switching. Rather than saving the state of performance monitoring hardware, which may not be possible in some hardware designs, when program execution is resumed, a delay is commenced to postpone analysis of the performance monitoring results until sufficient performance monitoring has been performed for the current execution cycle, in order to ensure accuracy of the results. In a particular embodiment of the present invention, the performance monitoring collects trace segments from branch history information in order to locate program hotspots for optimization, or other reasons for which the trace segment information is desirable. The trace segment information is not gathered until the branch history information has been sufficiently updated for each new execution cycle, preventing information from previous execution cycles of other programs from generating invalid segment analysis results. 
         [0018]      FIG. 1  shows a processing system in accordance with an embodiment of the present invention. The depicted processing system includes a number of simultaneous multi-threading (SMT) processors  10 A- 10 D. The depicted multi-processing system is illustrative, and processing systems in accordance with other embodiments of the present invention will have different configurations. Processors  10 A- 10 D are identical in structure and include cores  20 A- 20 B and local storage  12 , which may be a cache level, or a level of internal system memory. Processors  10 A- 10 D are coupled to main system memory  14 , a storage subsystem  16 , which includes non-removable drives and optical drives, for reading media such as a CD-ROM  17  for loading program code for execution by processors  10 A- 10 D, including program code that reads and analyzes branching information provided by hardware performance monitoring units within processors  10 A- 10 D, as well as operating system or hypervisor code that controls the switching of programs/tasks in accordance with embodiments of the present invention. The illustrated processing system also includes input/output (I/O) interfaces and devices  18  such as mice and keyboards for receiving user input and graphical displays for displaying information. While the system of  FIG. 1  is used to provide an illustration of a system in which the performance monitoring methodology of the present invention is implemented, it is understood that techniques of the present invention can be implemented in other architectures. It is also understood that the present invention applies to other processors in accordance with embodiments of the present invention that may be used in a variety of system architectures. 
         [0019]      FIG. 2  illustrates details of a processor core  20  that can be used to implement processor cores  20 A- 20 B of  FIG. 1 . Core  20  includes an instruction fetch unit (IFU)  22  that fetches instruction streams from L1 I-cache  21 A, which, in turn receives instructions from an L2 cache  23 . L2 Cache is coupled to a memory controller (MC)  37  that couples processor core  20  to a memory interface. Instructions fetched by IFU  22  are provided to an instruction decode unit  24 . A global dispatch unit (GDU)  25  dispatches the decoded instructions to a number of internal processor pipelines. The processor pipelines each include a mapper  26 A- 26 D, an issue unit  27 A- 27 D, an execution unit, one of branch execution unit (BXU)  28 , load/store unit (LSU)  29 , fixed-point unit (FXU)  30  or floating point unit (FPU)  31 , a write back unit (WB)  32 A- 32 D and a transfer unit (Xfer)  33 A- 33 D. A global completion unit (GCU)  34  provides an indication when result transfer is complete to IFU  22 . Mappers  26 A- 26 D allocate rename buffers  35  to represent registers or “virtual registers” indicated by instructions decoded by instruction decode unit  24  so that concurrent execution of program code can be supported by the various pipelines. Values in registers located in rename buffers are loaded from and stored to L1 D-cache  21 B, which is coupled to L2 cache  23 . Core  20  also supports out-of-order execution by using rename buffers  35 , as mappers  26 A- 26 D fully virtualize the register values. WBs  32 A- 32 D write pipeline results back to associated rename buffers  35 , and Xfers  33 A- 33 D provide an indication that write-back is complete to GCU  34  to synchronize the pipeline results with the execution and instruction fetch process. 
         [0020]    In illustrated core  20 , a performance monitoring unit  40  gathers information about operation of processor core  20 , including performance measurements, which in the illustrative embodiment are trace segment analysis results gathered by a trace segment detector  37 . Trace segment detector uses branch prediction and branch prediction accuracy information provided by a branch history table  39 , which receives information from a branch prediction unit  36  that may be provided only for performance monitoring, or which may also be used for speculative execution or speculative pre-fetching by processor core  20 . 
         [0021]    As execution of a program proceeds, branch prediction unit  36  updates branch history table  39  with a list of branch instructions that have been encountered, an indication of the most likely branch result for each of the branch instructions, and optionally a confidence level of the branch prediction. Trace segment detector  37  uses the information in branch history table  39  to distinguish segments of programs, and to provide useful information such as the number of times a particular segment has been executed. Since, with a few exceptions, branch instructions completely delineate patterns of program flow in which all instructions in a given segment are executed when the segment is entered, it is only necessary to collect the branch information in order to completely describe the segments of a program. In the present invention, a mechanism prevents trace segment detector from constructing segments, i.e., from analyzing the information in branch history table  39  until sufficient information has been updated for the current execution slice and/or program task session. 
         [0022]    Referring now to  FIG. 3 , details of performance monitoring unit  40  are shown, in accordance with an embodiment of the invention. Branch history table  36  provides branch execution information and branch prediction information to trace segment detector, which builds segment entries  41  in segment storage  42 . Segment entries  41  in the depicted embodiments are lists of addresses of branch instructions for which the branch was taken in the corresponding segment and a counter that indicates how many times the segment has been executed. Other or alternative information may be provided within segment entries  41  to provide additional information, or alternative descriptions permitting unique identification of the branch instructions within the segment. For example, segment entries  41  may include the target addresses of branch indirect instructions. Trace segment detector  37  begins building segment entries  41  in response to timer  38  indicating that a predetermined delay time has expired from the last context or task switch that activated the currently executing program. The delay prevents building segment entries  41  from invalid data in branch history table  36  either left from the last program, or left in an incorrect/inaccurate state at startup or other disruptive machine condition. While in the illustrative embodiment a time period timed by delay timer  38  is used, alternative embodiments of the present invention may count instruction cycles, or perform convergence evaluations of branch history table  36 , to determine when the branch history information is of sufficient quality to begin analyzing the segments. Further, while the illustrative embodiment is directed toward program trace analysis, the present invention is applicable to other performance monitoring techniques, such as workload measurements, thread or program processor resource usage accounting, and other performance monitor features that may not necessarily be accurately maintained across program context switches, either due to hardware limitations, or storage and I/O overhead limitations. 
         [0023]    In the particular embodiment illustrated, timer  38  is started and re-started each time a “1” is written to a control register (or a bit in a control register, which is understood to be a one-bit control register). By providing a readback of a “1” at the control register that is independent of the true state of timer  38 , the starting of timer  38  by a hypervisor (or other operating system or meta-operating system) that controls the task or context switching is automatically arranged, as long as the control register is part of the machine state saved at the context switch. Since, when the task is re-started, a value of “1” will always be written back to the control register, timer  38  will be started each time the context is switched. If the context is switched before timer  38  has expired, timer  38  will be restarted, which provides that performance monitoring data will only be analyzed for execution intervals that are of sufficiently duration. The timer can be a programmable value, or as mentioned above, the delay may be based on another count, for example, a count of the number of times a particular instruction is executed, where the address of the particular instruction may be specified by a register that has been previously written by a program, or the timer count may be incremented/decremented each time a branch instruction (or other type of instruction) is executed. 
         [0024]    Referring now to  FIG. 4 , a method of performance monitoring in accordance with an embodiment of the present invention is illustrated in a flowchart. Instructions are processed (executed) by processor core  20  on a continuous basis (step  60 ). If an instruction is a branch instruction (decision  61 ) the branch history table is updated with branching information, such as the location (relative addresses) of the branch instructions, along with the corresponding branch prediction state and branch prediction confidence (step  62 ). Until the delay timer has expired (decision  63 ), steps  60 - 62  are repeated without generating segment trace information. Also, if a programmable root instruction register is provided to trigger the segment tracing, then steps  61 - 62  are not performed until the root instruction is reached, then segment formation begins, but only after the delay timer has expired. Once delay timer has expired (decision  63 ), when a branch instruction is encountered (decision  61 ), the branch instruction is added to a current segment (step  64 ) and if the branch prediction was correct (decision  65 ), steps  60 - 65  are repeated until the system is shut down or the scheme is terminated (step  67 ), with the timer determination in decision  63  being subject to task/context switches that restart the timer. If the branch prediction was incorrect (decision  65 ), then two new segment entries are generated and one of the entries is selected as the current segment (step  66 ). 
         [0025]    Referring now to  FIG. 5 , the segment construction of the illustrative embodiment of the present invention is illustrated. Solid lines show predicted branches, and dashed lines show the other (non-predicted) branch directions. From branch instruction b 1 , which will be added to the current segment, on the early passes, the predicted branch is taken and belongs to segment  1 , as do branch instructions b 2 , b 6  and b 8 . The entry for segment  1  contains indications of branch instructions b 1 , b 2 , b 6  and b 8 , and segment one contains all of the instructions from branch instruction b 1  through the loop back to branch instruction b 1  from branch instruction b 8 . The entry for segment  2  is generated the first time branch instruction b 2  resolves in the non-predicted direction. Branch instruction b 5  is added to segment  2 , as is branch instruction b 7  once those instructions are encountered. Similarly, the entry for segment  3  is generated when branch instruction b 1  is observed taking the non-predicted direction. Branch instruction b 3  is added to segment  3 , as is branch instruction b 5 . However, if branch instruction b 5  resolves to the non-predicted direction during execution of segment  3 , branch instruction b 8  will be added to a new segment  5 . Similarly if branch instruction b 3  resolves to the non-predicted direction, then branch instruction b 4  is added to a new segment  4 . 
         [0026]    The result of the above processing is a collection of segments in which only one instance of a branch instruction indication appears for each branch instruction reached, and that does not grow unless branch instructions are observed taking non-predicted directions. Further, a count is generally maintained that is incremented at each entry to a segment. Since branch prediction information is continually updated, if execution centers around one particular execution path, the count for that execution path will be much greater than the others, and can be targeted for optimization. The present invention ensures that stale branch prediction data is not used in forming the segments by using delay or other postponement of the segment formation. If the segment formation was not postponed, the segments formed in the method illustrated in  FIG. 5  could be inaccurate and not represent the actual characteristics of the branch instructions, since the data guiding the segment formation was developed during execution of another program. The postponement ensures that the data guiding segment formation has been collected during execution of the current program. 
         [0027]    As noted above, portions of the present invention may be embodied in a computer program product, which may include firmware, an image in system memory or another memory/cache, or stored on a fixed or re-writable media such as an optical disc having computer-readable code stored thereon. Any combination of one or more computer readable medium(s) may store a program in accordance with an embodiment of the invention. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. 
         [0028]    In the context of the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. 
         [0029]    While the invention has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form, and details may be made therein without departing from the spirit and scope of the invention.

Technology Classification (CPC): 6