[ Home | Resume | Programming | Engineering Philosophy | Family ]

Some Thoughts on Resource Management

Resources are limited. Obtaining the maximal usefulness from limited resources is a perpetual problem. However, when we look to the successful and widely accepted methods for managing resources in computer operating systems, a pattern emerges. This pattern is alleged to be applicable to managing resources in general, including personnel, space and equipment.

Have Sufficient Resources

Do not plan to accomplish more than can be supported by the available resources. In the short term, resources are typically fixed, in which case the activities with the least Expected Return On Investment (EROI) should be abandoned until the remaining activities can be supported. In the long term, resources are variable, in which case sufficient resources should be obtained in order to support all activities with an attractive EROI. (What constitutes an "attractive" EROI depends on many things, but at a minimum it means exceeding that of trivial alternatives, such as investing in an S&P500 index fund.)

The assessment of the EROI must be realistic. The proposer of an activity will tend to overstate its return and understate its investment in order to improve its chances of approval. Rewarding this tendency is to be avoided, because underestimating the actual required resource investment results in having insufficient resources. This puts you in the awkward position of having either to abandon your investment in some promising activities, or to cause many activities to fail due to resource exhaustion.

Do not expect resources to be 100% utilized. Queuing theory teaches us that as utilization approaches 100%, wait time approaches infinity, which translates into some activities being unexpectedly stalled for long periods of time. One must also consider the context switch overhead associated with each reallocation of resources. For some types of resources, appropriate utilization levels might even be quite low.

Limit Resource Hogging

Even when there are enough resources to carry out the planned activities, resources can still be exhausted by accident or through negligence or greed. This can be addressed by having a mechanism to prevent a single activity from consuming all remaining resources at the expense of other activities, such as enforcing hard limits on the resources utilized by each individual.

Limiting resource hogging does not necessarily mean guaranteeing a minimum resource allocation to each individual, since this implies that resources can remain unutilized even when they are needed. However, it does preclude a single errant or greedy activity from exhausting shared resources regardless of how frugally other activities are undertaken.

In general, shared resources ought to be oversubscribed in terms of the sum of all individuals' maximum utilization as long as global exhaustion is rare, and undersubscribed in terms of average utilization up to the point that the wait time is acceptable.

Have Dedicated Resources for Critical Activities

Even when there are enough resources and resource hogging is limited, resource exhaustion can still occur. However, the consequences of having certain activities wait or fail due to resource exhaustion can be unacceptable. Such activities include signaling the exhaustion of resources, as well as activities on which many other activities rely. This problem can be addressed by having dedicated resources for such activities.

The average utilization of such dedicated resources may be very low indeed, perhaps even approaching zero. This is offset by the fact that the amount of resources that need to be dedicated is typically small, and that the value of having those resources available when they are needed is typically great.

It is theoretically possible for dedicated resources to be exhausted, but the system should be architected such that this happens only when the system is broken at a fundamental level, in which case resource exhaustion is probably the least of your worries.

Anders Johnson, last modified $Date: 2002/02/05 $

[ Home | Resume | Programming | Engineering Philosophy | Family ]