International Business Machines Corporation

Venkat Rajeev Indukuru

Alexander Erik Mericas

Robert H Bell, Jr

Madhavi Gopal Valluri

Pattabi Michael Seshadri

Giles R Frazier

Rajendra D Panda

Wen-Tzer Thomas Chen, Jr

Donald R DeSota

Francis Patrick O'Connell

Philip Lee Vitale

Randall Ray Heisch

Guy L Guthrie

Karthick Rajamani

Heather Lynn Hanson

Sameh Sherif Sharkawi

John Fred Spannaus

Joseph H Robichaux

William A Bostic

Jesse L Sathre

Thomas W Chen, Jr

Richard James Eickemeyer

Satish Kumar Sadasivam

Brian R Konigsburg

Aaron Christoph Sawdey

Steven Paul Hartman

Benjamin W Stolt

Benjamin Nowak

Zhong Liang Wang

Luigi Brochard

Alex E Mericas

Daniel Owen

Allan E Johnson

Balaram Sinharoy

Ronald P Hall

Mauricio J Serrano

Peter Joseph Heyrman

Mysore Sathyanarayana Srinivas

Miles Robert Dooley

Richard William Doing

Carl E Love

Donald R Desota

Allen E Johnson

Mechanisms are provided for a graphical user interface tool for system-wide topology and performance monitoring with per-partition views. A graphical user interface application presents a consolidated view of physical and logical information based on the received performance data. The mechanisms provide real-time performance and utilization information in a visual format relative to the physical components in a topographical layout. The user may drill down to lower levels to view more detailed performance and utilization information.

System-wide topology and performance monitoring GUI tool with per-partition views

A processor system tracks, in at least one counter, a number of cycles in which at least one execution unit of at least one processor core is idle and at least one thread of the at least one processor core is waiting on at least one off-core memory access during run-time of the at least one processor core during an interval comprising multiple cycles. The processor system evaluates an expected performance impact of a frequency change within the at least one processor core based on the current run-time conditions for executing at least one operation tracked in the at least one counter during the interval.

Tracking pipelined activity during off-core memory accesses to evaluate the impact of processor core frequency changes

A performance monitor including a saturating counter provides a relative measure of event frequency without requiring a minimum polling rate or periodic reset to avoid or account for counter overflow. The saturating counter is incremented upon detection of an event and decremented if an event is not detected within a predetermined period. The period of detecting may be programmable and may be determined by real time clock, processor or instruction cycles. Multiple event types may be selected from for detection and input to a single counter, or alternatively multiple event counters may be provided for various event types. The saturating counter may additionally be periodically reset in a selected operating mode, in combination with the decrementing action performed on the counter.

Processor core having a saturating event counter for making performance measurements

A hint bit detection and correction method and system that uses two additional bits as part of every cache directory. These bits represent the lwarx and stwcx instructions (larx disp, stcx disp). When a hint bit event occurs, depending the on combination of these two bits, there can be an indication of a hint bit error. Once a hint bit error is detected a software interrupt is issued and the hint bit correction method identifies and corrects the incorrect hint bit.

Dynamic detection and correction of incorrect lock and atomic update hint bits

A hint bit detection and correction method uses two additional bits as part of every cache directory. These bits represent the lwarx and stwcx instructions (larx disp, stcx disp). When a hint bit event occurs, depending the on combination of these two bits, there can be an indication of a hint bit error. Once a hint bit error is detected a software interrupt is issued and the hint bit correction method identifies and corrects the incorrect hint bit.

Dynamic detection and software correction of incorrect lock and atomic update hint bits

During a pipeline stall in a processor, until a next to complete instruction group completes, a monitoring unit receives, from a completion unit of a processor, a next to finish indicator indicating the finish of an oldest previously unfinished instruction from among a plurality of instructions of a next to complete instruction group. The monitoring unit receives, from functional units of the processor, finish reports including completion reasons for separate instructions. The monitoring unit determines at least one stall reason from among multiple stall reasons for the oldest instruction from a selection of completion reasons from a selection of finish reports aligned with the next to finish indicator from among the finish reports. Once the monitoring unit receives a complete indicator from the completion unit, indicating the completion of the next to complete instruction group, the monitoring unit stores each determined stall reason aligned with each next to finish indicator in memory.

Determining each stall reason for each stalled instruction within a group of instructions during a pipeline stall

Methods, systems, and computer program products may provide delay-identification in data processing systems. An apparatus may include a delay-identification unit having a delay counter, a threshold register, a delay register, and a delay detector. The delay detector may be configured to start the delay counter in response to detecting that one group of instructions is delayed, and stop the delay counter in response to detecting that the one group of instructions is no longer delayed. The delay detector may additionally be configured to compare the number of cycles counted by the delay counter with a threshold number of cycles in the threshold register, and store at least one effective address of one of the instructions of the one group of instructions when the number of cycles counted by the delay counter is greater than the threshold number of cycles stored in the threshold register.

Prioritizing instructions based on the number of delay cycles

According to one aspect of the present disclosure a method and technique for managing memory access is disclosed. The method includes setting a memory databus utilization threshold for each of a plurality of processors of a data processing system to maintain memory databus utilization of the data processing system at or below a system threshold. The method also includes monitoring memory databus utilization for the plurality of processors and, in response to determining that memory databus utilization for at least one of the processors is below its threshold, reallocating at least a portion of unused databus utilization from the at least one processor to at least one of the other processors.

Reallocating unused memory databus utilization to another processor when utilization is below a threshold

In-memory accumulation of hardware counts in a computer system is carried out by continuously sending count values from full-speed hardware counter units to a memory controller. A sending unit periodically samples performance data from the hardware counter units, and transmits count values to a bus interface for an interconnection bus which communicates with the memory controller. The memory controller responsively updates an accumulated count value stored in system memory using the current count value, e.g., incrementing the accumulated count value. A count value can be sent with a pointer to a memory location and an instruction on how the location is to be updated. The instruction may be an atomic read-modify-write operation, and the memory controller can include a dedicated arithmetic logic unit to carry out that operation. A data harvester can then be used to harvest accumulated count values by reading them from a table in system memory.

Continuous in-memory accumulation of hardware performance counter data

A processor performance profiler is enabled to for identify specific instructions causing performance issues within a program being executed by a microprocessor through random sampling to find the worst-case offenders of a particular event type such as a cache miss or a branch mis-prediction. Tracking all instructions causing a particular event generates large data logs, creates performance penalties, and makes code analysis more difficult. However, by identifying and tracking the worst offenders within a random sample of events without having to hash all events results in smaller memory requirements for the performance profiler, lower performance impact while profiling, and decreased complexity to analyze the program to identify major performance issues, which, in turn, enables better optimization of the program in shorter developer time.

Autonomic hotspot profiling using paired performance sampling

A computing device identifies a load instruction and store instruction pair that causes a load-hit-store conflict. A processor tags a first load instruction that instructs the processor to load a first data set from memory. The processor stores an address at which the first load instruction is located in memory in a special purpose register. The processor determines where the first load instruction has a load-hit-store conflict with a first store instruction. If the processor determines the first load instruction has a load-hit store conflict with the first store instruction, the processor stores an address at which the first data set is located in memory in a second special purpose register, tags the first data set being stored by the first store instruction, stores an address at which the first store instruction is located in memory in a third special purpose register and increases a conflict counter.

Identifying load-hit-store conflicts

Growing community of inventors

Austin, TX, United States of America

Venkat Rajeev Indukuru