CCSM Overview

• We use the word computation to refer to an activity that is meaningful to a human being which is performed by a computer and it is expected that the execution of computations is efficiently supported by computer systems.
• In general people write programs to implement computations but in virtually all modern operating systems, the program written, while the most visible, is not a full implementation of the computation.
• A system which attempts to maintain a computation oriented view of its activities must thus use an explicit representation of the set of computation components comprising that computation.
• Computation components can be divided into active and passive types.
  • An active component in Linux is represented by a task structure at the kernel level. This component can be a kernel thread, a user level thread, or a user level process.
    • Some independently executing components are necessary for application program execution. At the kernel level, these include: hardIRQ’s, softIRQ’s, tasklets, and work queues. At the user level these include: X-server, DBUS system and per-session server for DBUS, inetd, sshd, named, etc.
  • A passive component can be any of a wide range of system level resources, including: sockets, pipes, named pipes, shared memory segments, etc.
• A computation is thus represented by the set of all active and passive components used in the course of executing the program implementing computation.
• Under the current KUSP framework we have two primary motivations for keeping track of sets of computation components, control and measurement of computations. Control of computations is accomplished under the Groups Scheduling framework, in which a computation is represented by one or more groups of components with associated Scheduling Decision Functions. Measurement is accomplished under the Datastreams framework, in which instrumentation points produce event records as threads within the system execute specific pieces of code. The set of event records can then be analyzed either online or offline to construct a view of computation behavior.
• System level views of computational activity and control of sets of computations can be accomplished by composing computational level set representations into higher level sets.
• CCSM exists to support basic set management of computation components and includes the vital capability of associating a name with each set. This naming support then makes various aspects of Group Scheduling and Datastream use much more effective and efficient.
• The rest of this document first describes the CCSM API and then illustrates its use to accomplish various goals within the KUSP framework.