It is common practice today to design complex safety-critical systems by repurposing hardware and software components originally designed for other contexts and using such components in a "black-box" fashion. However, if a black box’s inner workings are not fully understood, then this can be unsafe. This paper reports on an investigation pertaining to a black box that is important for autonomous systems, namely NVIDIA’s CUDA GPU framework. This investigation was motivated by certain timing glitches in CUDA kernels reported in the literature. After extensive tracing and testing efforts, the culprit causing these glitches was surprisingly found to be not CUDA-related at all, but rather delays due to system management interrupts (SMIs), a known source of timing unpredictability on x86 machines that is rarely if ever mentioned in work on real-time GPU usage. The effects of these SMIs are invisible to the operating system and can cause all cores on an x86 machine to become unavailable for over 20ms! This paper describes the methods used to uncover this timing-glitch source. It also discusses some lessons learned when trying to validate the timing behavior of black-box components.

Article Continuous profiling: where have all the cycles gone? Share on Authors: Jennifer M. Anderson View Profile , Lance M. Berc View Profile , Jeffrey Dean View Profile , Sanjay Ghemawat View Profile , Monika R. Henzinger View Profile , Shun-Tak A. Leung View Profile , Richard L. Sites View Profile , Mark T. Vandevoorde View Profile , Carl A. Waldspurger View Profile , William E. Weihl View Profile Authors Info & Claims SOSP '97: Proceedings of the sixteenth ACM symposium on Operating systems principlesOctober 1997 Pages 1–14https://doi.org/10.1145/268998.266637Published:01 October 1997 175citation1,209DownloadsMetricsTotal Citations175Total Downloads1,209Last 12 Months17Last 6 weeks3 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

This article describes the Digital Continuous Profiling Infrastructure, a sampling-based profiling system designed to run continuously on production systems. The system supports multiprocessors, works on unmodified executables, and collects profiles for entire systems, including user programs, shared libraries, and the operating system kernel. Samples are collected at a high rate (over 5200 samples/sec. per 333MHz processor), yet with low overhead (1–3% slowdown for most workloads). Analysis tools supplied with the profiling system use the sample data to produce a precise and accurate accounting, down to the level of pipeline stalls incurred by individual instructions, of where time is bring spent. When instructions incur stalls, the tools identify possible reasons, such as cache misses, branch mispredictions, and functional unit contention. The fine-grained instruction-level analysis guides users and automated optimizers to the causes of performance problems and provides important insights for fixing them.

No abstract available.

A tracing facility called ATUM-2 that allows the capture of large address traces of multiprocessors is described. The method is based on a previous scheme called address tracing using microcode (ATUM) for single processors (see ibid., vol.13, p.119-27, (1986)). In ATUM, the microcode of a machine is modified to record the address of the memory references as a side effect of normal execution. The addresses are recorded in a reserved portion of main memory, and periodically transferred to disk. The ATUM-2 implementation on a VAX 8350 multiprocessor is described and the use of the resulting traces to analyze physical versus virtual addressing of large caches, process-identifier hashing in virtual caches, cache interference between multiple processes, cache interference between multiple CPUs, process affinity, and semaphore usage in writeback caches is reported on.>

Trace-driven simulation is often used in the design of computer systems, especially caches and translation lookaside buffers. Capturing address traces to drive such simulations has been problematic, often involving 1000:1 software overhead to trace a target workload, and/or mechanisms that cause significant distortions in the recorded data. A new technique for capturing address traces has been developed to use a processor's microcode to record addresses in a reserved part of main memory as a side effect of normal execution. An experimental implementation of this technique on a VAX 1 8200 processor shows a number of advantages over previous techniques, including fewer distortions of the address trace and a hundred times faster recording. With this technique, it is possible to gather full operating-system traces of multi-tasking workloads.

Abstract In some compilers, long identifiers are truncated, or lower case letters are converted to upper case. Such respellings can make two distinct identifiers appear identical, and under unfavourable circumstances no warning or error messages will be generated. The use of different respelling algorithms in different compilers is a hindrance to transporting software, and is a source of latent bugs. This short note suggests avoiding the problem by generating warning messages when a potentially ambiguous spelling is used in a declaration. The technique involves hashing the character and case‐shift bits that would otherwise be thrown away. A program that compiles without warning messages can be safely transported.

In an optimizing compiler, it is often desirable to compile subscript expressions such as Abase-2 + I*2 so that the value of the expression is available in a register and is simply incremented whenever I is incremented, thus avoiding the multiplication inside the loop. This change is effected by a standard optimization called strength reduction. Program loops often contain several such expressions stemming perhaps from references to operands A(I), A(I+1), B(I), and C(K,J,I,L). Under what circumstances can we do better than keeping four addresses in four separate registers or temporaries? A general technique is presented which minimizes the number of registers needed to hold such values, while simultaneously minimizing the amount of computation inside the loop. In the above collection, it is possible to use as few as two registers for the four I-dependent values.

The Cray-1 is an extremely high-speed computer, intended to be used for large floating-point scientific computations. However, it is a well-balanced machine that can gracefully be used on a wide class of problems. The machine has two major architectural innovations: (1) 128 backup registers which represent a new layer in the memory hierarchy, essentially a programmer or compiler-managed cache, and (2) 8 vector registers holding up to 64 words each, and operated on by vector instructions. In this paper, we will describe the entire machine, discuss efficient ways to use the 656+ programmer-accessible registers, and discuss some of the design shortcomings.

A technique is presented for dividing a positive binary integer by ten, in which the bits of the input are presented serially, low-order bit first. A complete division by ten is performed in two word times (comparable to the time needed for two serial additions). The technique can be useful in serial conversions from binary to decimal, or in scaling binary numbers by powers of 10.