next up previous contents
Next: STATE REPRESENTATION IN THE Up: ECS SYSTEM ARCHITECTURE Previous: Class-codes

Allocation blocks

As we shall see below, the representation of each ECS object occupied space in ECS. It was necessary to ration this space among prospective users. Since we expected that a single user might be associated with more than one process, we decided to ration ECS space through a more general entity, an allocation block. Each ECS object, including allocation blocks, had to belong to some allocation block. (A special root allocation block was exempted from this requirement.) All actions that created objects required an allocation block as one parameter. This allocation block was checked for sufficient free space, which was then allocated to the new object. For objects which could change size (files and processes) space was moved to or from their allocation block. In addition to rationing the use of ECS space, allocation blocks metered the ECS space used by objects. This meter recorded the time integral of the ECS space used by objects belonging to the block. Moreover, other resources were to be rationed and metered by allocation blocks. These were to include MOT slots (see chapter 8) and CPU time. In fact, meters for both were installed, but rationing was never installed for CPU time. (Also, the eventual accounting system read the meters for ECS space-time and CPU time, but not MOT slots.) New allocation blocks could be created, and space could be moved about the tree of allocation blocks. A special action was implemented, to be used only by the disk system, which could move space from one allocation block to another, while the space continued to be included in the space time integral of the first block. This permitted the disk system to borrow space from a user and have the user continue to pay for it.
next up previous contents
Next: STATE REPRESENTATION IN THE Up: ECS SYSTEM ARCHITECTURE Previous: Class-codes
Paul McJones
1998-06-22