Browse Prior Art Database

Performance Information Gathering in a Multiprogramming System

IP.com Disclosure Number: IPCOM000075512D
Original Publication Date: 1971-Oct-01
Included in the Prior Art Database: 2005-Feb-24
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Harrison, WH: AUTHOR

Abstract

A multiprogramming system may be treated as a collection of parallel linear streams of processing from which the system selects one stream to be processed at any given time. Generally the same stream continues being processed until some event occurs which alters the choice of the stream.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Performance Information Gathering in a Multiprogramming System

A multiprogramming system may be treated as a collection of parallel linear streams of processing from which the system selects one stream to be processed at any given time. Generally the same stream continues being processed until some event occurs which alters the choice of the stream.

In analyzing the performance of a multiprogramming system, it is common practice for the analyst to construct, in his mind even if not on paper, a finite state model of the linear streams in terms of processing states that denote the various phases which a linear stream may pass through, and transition events which signify a change in the state of a process. For example, in a time sharing system, the activity of the computer programs executed by each user is representable as a linear processing stream. In such a system, the user's program may be executing, waiting for I/O, being swapped in, or being swapped out, and the events which cause transitions might be requests for I/O, I/O completion, timer expirations, or completion of a swapping operation. Such a model is a prerequisite to any analysis of system performance.

It is possible when designing a multiprogramming system, to define those system wide events which will often correspond to those events which analysts will choose for defining the transitions between the states in their model of the system. Such events generally include l) events which cause the system to operate on a different linear stream, 2) events which relate to the scheduling of processing of various streams, 3) events which relate a processing stream to the external world, e.g. source/sink I/O and terminal communications, and 4) events which describe the flow of control of the processing stream as it proceeds from program to program. Of course, any such attempt at event definition should allow for the placement of new event signals required by the analyst. Upon detection of any of these significant events, the system can be constructed to record a description of the event to an event log. Each entry in the log should contain the event description and some tag, which can be used to identify the linear stream to which the tag is related. A special tag can be used to indicate that the event is not specifically related to any one linear stream, but may be relevant to...