Any user-supplied code operating under IRIX.
See event collection.
See context switch, current context, process context.
The IRIXview window that lets you examine event data logged about your software system. In this window, time is represented on the horizontal axis, while the current system's contexts are represented on the vertical axis.
Starting from the top of the screen, the interrupts used in the system are listed first. The interrupts are followed by the processes, with the process first recording events listed first, followed by others as they record events.
The last context shown is the processor's idle thread.
An operation performed by a multitasking operating system in which the current thread of execution is switched for another. Examples of this are one process preempting another, a process delaying itself or pending on a resource (making the processor available for another thread of execution), or a process being interrupted by an ISR. See also current context, process context.
A graph that displays data of up to X processors. To open a CPU View Graph for current data or for a saved *.irv file, choose Windows > New CPU Graph in the IRIXview main window.
A state when a process is “starving” for CPU time. In other words, the process never gets to run, because it is never scheduled by the IRIX scheduler.
In operating system jargon, the currently executing process and information needed to restore the process's state, such as the state of the processor registers, operating system control information, and the stack. For IRIXview, the meaning has been extended to include ISRs and the kernel's idle thread. See process context.
When two or more processes keep each other from running; for example, when processA is pending on a semaphore waiting to be unblocked by processB, but processB is pending on another semaphore waiting to be unblocked by processA. This is a common bug in software systems, easily diagnosed with IRIXview.
In IRIXview, any action undertaken by a process or an ISR that can affect the state of the system. Examples of events are process spawns and deletions, timer expirations, and interrupts. IRIX has been instrumented to log this event information. See also event logging, IRIXview logging mode, instrumented code, user-generated events.
An area of memory in IRIX that temporarily holds the event data before it is processed by IRIXview, when you are using the GUI to collect event data.
Information that is logged to the IRIXview event buffer.
The process of starting event logging under IRIX, and then capturing the event data to the event buffer.
An icon displayed in the View Graph that correspond to an event. For information on what each event icon represents, see the Legend window. To learn specific information on a particular instance of an icon, use the Event Inspector window.
A window that displays information about an event: its name, its timestamp, the context in which it occurred, and any other event information that has been logged. Use the middle mouse button to select any event icon in the View Graph and drag it into the Event Inspector window to display this information.
A finite collection of event data that resides in shared memory. Event log data is collected using rtmon_client or by using the Target dialog in IRIXview (choose Windows > Target from the IRIXview menu). You can open previously saved event logs in IRIXview by choosing File > Open.
The target activity of writing information about events to the IRIXview event buffer as the events occur. You start event logging with rtmon_client or with the Start button in the IRIXview Target window (choose Windows > Target from the IRIXview menu).
The state when a process or other context has control of the processor. For a process to be in the executing state, there must be no interrupts to service. ISRs are in the executing state after their interrupt has been acknowledged by the kernel; if there is more than one ISR to service, the one at the processor's highest interrupt level executes. The idle thread is in the executing state when there are no processes to run and no ISRs to service. See also current context, process state, process state transition.
See thread of execution.
Graphical user interface: the portion of IRIXview running on the system or X terminal with which you view event data.
When there are no processes ready to execute and no interrupts to service, the kernel enters its idle thread. In this “state,” the kernel services interrupts and continually checks to see if a process is ready to run. Analyzing the amount of time your application is idle can help you fine-tune the application: too much time in the idle thread may mean the application is not using the processor efficiently; too little time may mean that the application is interrupted too often to run effectively.
Instrumented code is software that has been modified to provide information about its own operation. In the case of IRIX, this information is event data that contains a record of the significant moments in the flow of control within the operating system. Application code can be instrumented with the rtmon_log_user_tstamp() routine; see user-generated events.
An interrupt is a signal from hardware that lets the processor know that something has occurred in the external world. For example, the processor may receive an interrupt when a clock tick occurs or when a character is received on a serial port. See also Interrupt Service Routine (ISR).
See Interrupt Service Routine (ISR).
Interrupt latency is the amount of time during which the processor's ability to respond to interrupts is inhibited. Both the hardware and software architecture contribute to interrupt latency. Hardware influences on interrupt latency include such things as prioritizing interrupt requests and preventing interrupt handling until the completion of lengthy instructions. Software influences stem from mode switches, context switches, and kernel preemption latencies.
A routine called when a particular interrupt occurs. Also known as an interrupt handler. For example, when a character is received on a serial port, the associated ISR is called to handle that interrupt. (Handling such an interrupt typically consists of copying the input character to a buffer and clearing the serial device for the next character.) ISRs run in a special interrupt-level context, which is separate from any process's context.
Mechanisms that allow processes to synchronize and communicate so that they can coordinate their activity. The IRIX interprocess communication mechanisms include semaphores, message queues, pipes, sockets, and signals.
In IRIXview, the amount of overhead added to the target IRIX system by including instrumented code and starting event logging.
A mode that shows the current context and where it is switched. The current context is shown as a solid horizontal line. When a context switch occurs, a dotted vertical line connects the previous context's line to the current context's line.
IRIXview window that shows what each event icon and state stipple represents. It can be displayed with the Legend Window icon on the View Graph.
The time it takes for a thread to switch from kernel mode to user mode.
In a View Graph, the width of the current time interval; that is, the portion of the event log currently displayed in the View Graph.
A state when a process attempts to obtain an object or resource but the object or resource was not available; for example, if it made a call to obtain a semaphore, but the semaphore was not available. A process in this state is also known as a blocked process. See also process state transition.
When a process becomes ready to execute and has a higher priority than the currently executing process, and the “new” process preempts the current process. That is, the operating system saves the current process's context and switches to the context of the higher-priority process. See also process state transition.
In IRIX, each process is assigned a priority, and the kernel ensures that the processor is allocated to the highest-priority ready process. The scheduling is preemptive in that if a process of a higher priority than the executing process becomes ready, the kernel preempts the current process and switches to the higher-priority process. See also context switch, process state transition.
The standard IRIX scheduler provides 256 process priority levels, numbered 0 (highest) through 255 (lowest). Processes are assigned a priority when created; however, while executing, a process may change its priority using schedctl(2).
An independent program or application that has its own job to perform, such as the management of a robot arm. Each process has its own context, which is the processor environment and system resources the process “sees” each time the kernel schedules it to run. On a context switch, a process's context is saved. Processes can communicate and synchronize with each other through interprocess communication mechanisms (IPCs).
A process consists of an address space containing the program text and data, and a number of process attributes managed by the IRIX kernel. A few examples of process attributes are: a unique process ID number; machine register contents, representing the current instruction and stack level as well as working data; UNIX user and group identities; current working directory for file searches; and signal-handling status.
For applications, process states include the following: executing, ready, and suspended.
This term refers to the action of a process exiting from one state and entering into another (this is different from context switch, which refers to a change in the controlling context within the processor). A process state transition may or may not result in a context switch, depending on the states of other processes in the system when the process in question makes its transition between states.
A blockage that occurs when the outcome of a process is erroneously determined by one of two or more events (for example, is a particular variable read first, or updated first?). This kind of problem can often be avoided by using mutual exclusion semaphores to synchronize the process' use of the resource.
A state when a process is waiting for no other resources besides the processor—it is on the run queue, but has not yet executed. See also process state, process state transition.
A system object for which a process may contend with other processes. Examples of resources are memory pool data structures, message queues, and semaphores. If the resource is not available, a process contending for that resource makes a transition to the pended state. See also process state transition.
See executing state.
See preemptive priority scheduling.
A predefined message sent between two processes or from the kernel to a process. IRIX supports UNIX BSD-style signals as well as POSIX-compatible signals for asynchronous transfer of control within a process, based on hardware or software exceptions. The IRIX software signaling facility provides a set of 31 distinct signals. A process can specify a signal handler routine to take appropriate action when the associated signal is received. When signal handling is complete, normal process execution resumes, unless the signal corresponds to an exception.
A UNIX BSD 4.3-compatible interface for transferring byte streams between processes, regardless of location in a networked application.
See process state.
The horizontal lines on the View Graph that show the current state of each process in the system. The Legend window provides information about stipple types.
The space between two time instants. Choose the first time instant with the left mouse button, then choose the second instant in the same way. Two vertical lines are displayed in the event log, and details about the sub-interval are displayed in the Detailed Time Information field. It can be useful to know the amount of time that has occurred between events, or to select a sub-interval that you zoom in on with the Zoom In icon.
In an IRIX system, this term refers to any code that is not application code. It includes the IRIX kernel, IRIX system libraries, device drivers, and so on.
The hardware timer, which runs continuously and emits a periodic interrupt known as a tick. IRIX uses the system clock to manage process scheduling, process delays, and so on.
The system where IRIXview is collecting events.
The sequence of instructions that a particular process (such as a process or ISR) executes to carry out its job.
A single point in time, selected with a click of the left mouse button in the View Graph. A vertical line appears in the event log, and details about the time instant are displayed in the Detailed Time Information field.
The portion of the event log currently displayed in the View Graph. If timestamping is enabled, the time interval is an amount of time. If sequential event display is used, the time interval is a number of events.
The amount of time each process is normally allowed to execute without being preempted. By default, the time slice is 3 ticks, or 30 milliseconds. Often, a typical process will be blocked for I/O before reaching the end of its time slice. At the end of a time slice, the kernel chooses which process to run next on the same processor, based on process priorities. When runnable processes have the same priority, the kernel runs them in turn.
The time recorded for an event. When the instrumented IRIX kernel is run with the accompanying rtmond monitoring daemon, certain logged events are tagged with a high-resolution timestamp. The events are displayed in the View Graph along a timeline showing when they occurred based on their timestamps.
See process state transition.
A process that is pended (blocked) on a resource is unblocked when the resource becomes available, its timeout expires, or it is explicitly unblocked.
Custom application-specific events that IRIXview can record and display. When event logging has been started, you can have IRIXview show these events by inserting calls to the rtmon_log_user_tstamp() function into your application source code.
See GUI.