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 and provides accurate performance monitoring information. When a hypervisor signals that a task is being resumed and the application privilege level has been entered, 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, a state due to execution of the operating system or hypervisor, 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 branch information in a current program execution trace.

Description:
This U.S. patent application is a Continuation-in-Part of U.S. patent application Ser. No. 13/079,189, filed on Apr. 4, 2011 and Claims priority thereto under 35 U.S.C. §120. The above-referenced parent U.S. patent Application is incorporated herein by reference, has at least one common inventor with, and is assigned to the same Assignee as, the present application. 
    
    
     BACKGROUND 
     1. Field of the Invention 
     The present invention is related to computer systems in which processor hardware facility state information is restored after context swaps, and in particular to techniques for ensuring that valid performance-monitoring hardware facility state information is used in subsequent activities. 
     2. Description of Related Art 
     In computer systems, hardware facilities in a processor can be provided for making performance measurements, tracking program execution, or other purposes. Computer system performance can be improved by monitoring the performance of the computer system or behavior of the programs. 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. 
     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. 
     A particular performance monitoring technique, as disclosed in the above-incorporated parent U.S. patent Application, entitled “TASK SWITCH IMMUNIZED PERFORMANCE MONITORING”, delays performance monitoring operation, i.e., the use of the information collected by the hardware performance-monitoring facilities after a context switch occurs, to avoid using invalid performance monitoring states. 
     BRIEF SUMMARY 
     The invention is embodied in a method, a computer system and a processor core, 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 a timer has elapsed, the timer being set when an application privilege level process begins execution after a context swap, so that the performance monitoring information does not reflect execution of the operating system and/or hypervisor. 
     The performance monitoring output or analysis may be delayed for a predetermined time period or instruction cycles, and is triggered by a computer program such as a hypervisor indicating that the application execution state has been entered after a context swap. After the delay has expired, the performance monitoring results may be analyzed. 
     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 further 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. 
     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 
       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: 
         FIG. 1  is a block diagram illustrating a computer system including in which techniques according to an embodiment of the present invention are practiced. 
         FIG. 2  is a block diagram illustrating details of processor cores  20 A- 20 B in the computer system of  FIG. 1 . 
         FIG. 3  is a simplified electrical schematic showing details of performance monitoring unit  40  of  FIG. 2  in accordance with an embodiment of the present invention. 
         FIG. 4  is a timing diagram illustrating signals within performance monitoring unit  40  of  FIG. 3 . 
         FIG. 5  is a flowchart of a method of performance monitoring within a processor core in accordance with an embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     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. Since the state of the hardware facilities that assist in performance monitoring are not generally restored, when a context swap occurs, the state of the performance monitoring hardware may reflect execution of the operating system or hypervisor. The present invention provides a mechanism for ensuring that the performance monitoring information obtained from a performance monitoring hardware facility reflects the actual execution of an application of interest by detecting that a write to the performance monitoring facility that indicates a restore due to the context swap, further detecting that the privilege level of the system has entered the application privilege level, indicating that program execution has resumed, and starting a timer. After the timer has elapsed, analysis of the performance monitoring results can be resumed. 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 the hypervisor, supervisor (operating system) or other programs from generating invalid segment analysis results. 
       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. 
       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. 
     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 . 
     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 program task session. A control logic  38 , in accordance with an embodiment of the present invention, controls operation of trace segment detector  37 , so that trace segment detector  37  only uses information from branch history table  39  when the information is applicable to execution of the program for which performance measurements are being made, as will be described in further detail below. 
     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. Further, the techniques of the present invention may be applied to other hardware performance measuring facilities and control use of the measurement results produced thereby using the same techniques described below. Trace segment detector  37  begins building segment entries  41  in response to a control signal Enable provided from control logic  39 . Control signal Enable indicates that a predetermined delay time has expired from the start of execution of 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 caused by execution of a supervisor (OS) or hypervisor program. 
     Privilege level signals, generally provided from a thread state register, are provided to a logical AND gate AND 1  which determines when execution of the processor has entered application level (privilege level  11 ) and generates an indication app that the processor is executing at application privilege level. Another logical AND gate AND 2  qualifies indication app with the output of a latch Q 1  that is set when a write operation to trace segment detector  37  has occurred (wrtsd asserted), indicating that the hypervisor has restored the state of trace segment detector  37 , which occurs during hypervisor privilege level execution prior to the assertion of indication app. When latch Q 1  has been set and indication app is asserted, a control signal Start is asserted, causing a timer  43  to begin timing the predetermined delay time. At the end of the predetermined delay time, control signal Enable is asserted, and trace segment detector  37  begins building trace segments  41  from the information in branch history table  36 . Control signal Enable remains asserted until another write to trace segment detector  37  is detected (wrtsd asserted), indicating that the hypervisor has restored another context. While in the illustrative embodiment a time period timed by delay timer  43  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 after the application privilege level has been entered. 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. 
     Referring now to  FIG. 4 , operation of performance monitoring unit  40  is illustrated by showing signals within performance monitoring unit  40  in a timing diagram. Between times t 0  and t 1 , the processor is operating at application privilege level (PL1:PL0=11). At time t 1 , the processor executes at hypervisor privilege level (PL1:PL0=10) and the hypervisor initiates a context swap. At time t 2 , the hypervisor restores the state of the trace segment detector (wrtsd asserted), and control signal Enable is de-asserted if previously asserted. From time t 2  until time t 3 , the processor remains at hypervisor privilege level and from t 3  until time t 4 , the processor is at supervisor privilege level, during which time control signal Enable remains de-asserted. Finally, at time t 4  the processor begins executing at application privilege level, indication app is asserted, and control signal Start is asserted to start timer  43 . At time t 5 , the predetermined time period has elapsed and control signal Enable is asserted to enable trace segment detector  37 . 
     Referring now to  FIG. 5 , a method of performance monitoring in accordance with an embodiment of the present invention is illustrated in a flowchart. Initially, the use of performance data is disabled (step  60 ). When a write to a facility in the performance monitoring unit is detected (decision  61 ) and the application privilege level is subsequently entered (decision  62 ), then the timer is started (step  63 ). Once the timer has expired (decision  64 ), the use of the performance data is enabled (step  65 ). The use of the performance data remains enabled until another context switch is detected (decision  66 ), when execution is directed to step  60  again. Steps  60 - 66  are repeated until the system is shut down or the scheme is terminated (decision  67 ), with the timer determination in decision  64  being subject to task/context switches that restart the timer. 
     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. 
     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. 
     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.