Next: STATE REPRESENTATION IN THE
Up: ECS SYSTEM ARCHITECTURE
Previous: Class-codes
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: STATE REPRESENTATION IN THE
Up: ECS SYSTEM ARCHITECTURE
Previous: Class-codes
Paul McJones
1998-06-22