Resource reservations

Eclipse/BSD applications obtain a desired quality of service by initially acquiring a resource reservation for each required physical resource. Physical resources include CPU, memory, disks, and network interfaces, each managed by a scheduler. A resource reservation specifies a fraction of the resource set aside for exclusive use by one or more processes. Applications can subdivide resource reservations hierarchically. Admission control guarantees that reservations do not exceed resources. Eclipse/BSD's schedulers share fractions of the respective resource fairly among all applications currently using the resource, as explained in the rest of this subsection.

Applications specify resource reservations as directories in a new file system mounted under /reserv. Each independently scheduled resource in the system corresponds to a directory under /reserv: /reserv/cpu (CPU), /reserv/mem (physical memory), /reserv/fxp0 (network interface 0), /reserv/sd0 (disk 0), and so on, as shown in Figure 1. Devices with multiple independently scheduled resources correspond to multiple directories, whereas multiple jointly scheduled resources (e.g., mirrored disks) correspond to a single directory.

  

Figure 1: Eclipse/BSD's /reserv file system allows applications to create resource reservations.

A resource reservation r is called an internal reservation if it can have children, or a queue otherwise. r's parent p is always either /reserv or another reservation for the same resource. Each resource reservation r contains a share file that specifies two values: m_r, the minimum absolute value of the resources that r obtains from p, and $\phi_r$, the weight with which r shares p's resources. m_r is specified in units appropriate to the respective resource (e.g., SPECint95 for CPU, bytes for physical memory, or Kbps for disk or network interfaces). If p is /reserv, m_r = V, the entirety of the resource, and $\phi_r$ is 100%. The amount of resources apportioned to a reservation r, v_r, depends dynamically on what reservations actually are being used. Every request arriving at a scheduler must specify a queue for processing that request; the request is said to use that queue. Schedulers enqueue and service in FIFO order requests that use the same queue. A reservation r is said to be busy while there is at least one request that uses r or a descendent of r.

If a resource reservation r is internal, then it also contains the files newreserv and newqueue. By opening either of these files, an application creates an internal reservation or queue that is r's child, respectively. The open call returns the file descriptor of the newly created share file, initialized with m_r = 0 and $\phi_r = 0$. Internal reservations thus created are consecutively numbered r0, r1, and so on, whereas queues are numbered q0, q1, and so on.

If resource reservation r is a queue, then it also contains the file backlog. Writing into backlog clears the number of requests served and amount of service provided and sets the maximum number of requests and amount of service that may concurrently be waiting in the queue. Reading from backlog returns the number of requests served and the amount of service provided (in units appropriate to the respective resource, e.g. CPU time or bytes).

Eclipse/BSD prevents reservations from exceeding resources as follows. Let S_p be the set of p's children and $M_{S_p} = \sum_{i \in S_p} m_i$. Then writing into the share file of $r \in S_p$ is subject to the following admission control rule: the call fails if p is /reserv (i.e., the entirety of the resource has a fixed value), m_p < M_Sp (i.e., a parent's minimum resources must at least equal the sum of its children's minima after the attempted write), or $\phi_r < 0$(i.e., weights must be non-negative).

Eclipse/BSD shares resources fairly according to the weights of the busy reservations. If reservation r is not busy, then its apportionment is v_r = 0. Otherwise, let p be the parent of r, B_p be the set of p's busy children, and $\Phi_{B_p} = \sum_{i \in B_p} \phi_i$.If p is /reserv, then:

 

v_r = V (1)

where V is the entirety of the resource, else:  

$$v_r = \frac{\phi_r}{\Phi_{B_p}} v_p$$ (2)