Check out the new USENIX Web site. next up previous
Next: Schedulers Up: Resource management model Previous: Request tagging

Reservation garbage collection

The previous subsections described how resource reservations are created and used; this subsection explains how they are destroyed.

Each resource reservation has a reference count equal to the number of times the reservation appears in an rdom or crdom file or is pointed by an activation, memory region, or file descriptor. A process's rdom and crdom files are created when the process is forked and are destroyed when the process exits. The file descriptor of a share file in the /reserv file system points to the respective resource reservation; additionally, as described in the previous subsection, file descriptors for vnodes and sockets also point to the resource reservations they use. Eclipse/BSD updates reservation reference counts on process fork and exit, activation_switch, memory region allocation and deallocation, mreserv, file open or close, socket connect or accept, sendto, sendmsg, and fcntl F_QUEUE_SET.

A GC flag determines whether a resource reservation should be garbage-collected when the number of references to the reservation drops to zero. When a resource reservation is created, its GC flag is enabled, but a privileged process can disable it. New commands to the fcntl system call, F_COLLECT_SET and F_COLLECT_GET, can be used on the file descriptor of a reservation's share file to set or get the reservation's GC flag.

Garbage collection of a queue q may need to be deferred. If q is being used by at least one request, q cannot be removed immediately; instead, q's REMOVE_WHEN_EMPTY flag is set. When the last request that uses q completes and q's REMOVE_WHEN_EMPTY flag is set, if q's reference count is still zero, the scheduler garbage-collects q, else the scheduler resets the flag.

next up previous
Next: Schedulers Up: Resource management model Previous: Request tagging
Jose Brustoloni