International Business Machines Corporation

Philip Lee Vitale

Aaron Christoph Sawdey

Mark Robert Funk

Venkat Rajeev Indukuru

Rajarshi Das

Allan E Johnson

James Wilson Bishop

Randall Ray Heisch

Jesse L Sathre

William A Bostic

Michael Stephen Floyd

Michael Joseph Genden

Todd Jon Rosedahl

Christopher Francois

Steven Bradford Herndon

William John Starke

Dung Q Nguyen

Alexander Erik Mericas

Peter Joseph Heyrman

Steven R Kunkel

Jason Nathaniel Dale

Robert Dominick Mirabella

Carl E Love

Alex E Mericas

Douglas Robert Logan

Jim A Kahle

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

Systems, methods and computer program products assess processor performance metrics by monitoring probes constructed using instruction sequences. A first probe value can be determined from execution of a broad spectrum probe in an execution environment. In response to determining that the first probe value is not a first expected probe value, a targeted probe providing a second probe value directed to a subsystem of the execution environment, a feature of the subsystem, or a component of the execution environment is executed. In response to determining that the second probe value is not a second expected probe value, a differential between the second probe value and the second expected probe value can be used to determine that a bottleneck exists in at least one of the subsystem of the execution environment, the feature of the subsystem, or the component of the execution environment.

Assessment of processor performance metrics by monitoring probes constructed using instruction sequences

Apparatuses, methods, systems, and computer program products are disclosed for monitoring performance of multithreaded workloads. A workload module starts a workload comprising one or more threads. The workload reaches a steady state after a period of time. A data module receives a first set of performance data for each thread in response to the workload reaching the steady state. The first set of performance data is received concurrently for each thread. The data module receives a second set of performance data for each thread a period of time after the first set of performance data is received. The second set of performance data is received concurrently for each thread. A result module calculates one or more performance metrics for each thread based on the first and second sets of performance data.

Monitoring performance of multithreaded workloads

Apparatuses, methods, systems, and computer program products are disclosed for calculating a clock rate of a processor. A baseline data module receives a first set of performance data associated with a processor. The performance data is generated using a hardware element that captures performance data for the processor. The hardware element is external to the processor. An update data module receives a second set of performance data associated with the processor a predefined time interval after the first set of performance data is received. The second set of performance data corresponds to the first set of performance data. A rate module calculates a clock rate for the processor based on the first set of performance data and the second set of performance data.

Calculating the clock frequency of a processor

Processor performance metrics are assessed by monitoring probes constructed using instruction sequences. A probe comprising an instruction sequence is selected. The instruction sequence can be configured to measure at least one hardware metric. A first probe value is received. The first probe value can be based, at least in part, on the hardware metric. The first probe value can be determined from execution of the probe in a first execution environment. The probe can be executed a second time to determine a second probe value. The second probe value can be based, at least in part, on the hardware metric. The second probe value is determined in a second execution environment including at least one workload. The first probe value and the second probe value can be compared to produce a performance assessment of the second execution environment.

A method for storing service level agreement ('SLA') compliance data includes reserving a memory location to store SLA compliance data of a software thread. The method includes directing the software thread to run on a selected hardware device. The method includes enabling SLA compliance data to be stored in the memory location. The SLA compliance data is from a hardware counting device in communication with the selected hardware device. The SLA compliance data corresponds to operation of the software thread on the selected hardware device.

Storing service level agreement compliance data

An apparatus for storing service level agreement ('SLA') compliance data is disclosed. A method and a computer program product also perform the functions of the apparatus. The apparatus includes a reservation module that reserves a memory location to store SLA compliance data of a software thread. The apparatus includes a directing module that directs the software thread to run on a selected hardware device. The apparatus includes an enabling module that enables SLA compliance data to be stored in the memory location. The SLA compliance data is from a hardware counting device in communication with the selected hardware device. The SLA compliance data corresponds to operation of the software thread on the selected hardware device. At least a portion of the reservation, the module, and the enabling modules includes one or more of hardware and program instructions. The program instructions are stored on one or more computer readable storage media.

Monitoring probes constructed using instruction sequences are used to assess processor performance metrics. A probe comprising an instruction sequence is selected. The instruction sequence can be configured to measure at least one hardware metric. A first probe value is received. The first probe value can be based, at least in part, on the hardware metric. The first probe value can be determined from execution of the probe in a first execution environment. The probe can be executed a second time to determine a second probe value. The second probe value can be based, at least in part, on the hardware metric. The second probe value is determined in a second execution environment including at least one workload. The first probe value and the second probe value can be compared to produce a performance assessment of the second execution environment.

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

According to one embodiment of the present disclosure, an approach is provided in which a thread is selected from multiple active threads, along with a corresponding weighting value. Computational logic determines whether one of the multiple threads is dispatching an instruction and, if so, computes a dispatch weighting value using the selected weighting value and a dispatch factor that indicates a weighting adjustment of the selected weighting value. In turn, a resource utilization value of the selected thread is computed using the dispatch weighting value.

Region-weighted accounting of multi-threaded processor core according to dispatch state

An approach is provided in which a thread is selected from multiple active threads, along with a corresponding weighting value. Computational logic determines whether one of the multiple threads is dispatching an instruction and, if so, computes a dispatch weighting value using the selected weighting value and a dispatch factor that indicates a weighting adjustment of the selected weighting value. In turn, a resource utilization value of the selected thread is computed using the dispatch weighting value.

A computer configuration utility automatically alters system configuration parameters to sample multiple different configurations. At least one workrate metric is measured at each sampled configuration. The workrate measurements for the multiple different configurations are compared to determine the effect of different configurations with respect to at least one optimization criterion. System configuration is automatically adjusted to the optimum configuration. Preferably, the workrate metric is (non-idle) instructions executed per unit of time.

Growing community of inventors

Rochester, MN, United States of America

Philip Lee Vitale