Resource Management | Komputasi | Suatu Permulaan

8.2 Resource Management

We now turn to more concrete principles, starting with resource management. This is done in two dimensions: time and space. Use small fixed chunks Contiguous allocation suffers from fragmentation in space and is inflexible in time. The solution is to partition the resource into small chunks of a fixed size for allocation, and use some mechanism to map the desired contiguous range onto non-contiguous chunks. Examples include: • Memory is allocated in pages that are mapped to the address space using a page table. • Disk space is allocated in blocks that are mapped to files using the file’s index structure. • Network bandwidth is allocated in packets that are numbered by the sender and reassembled at the destination • In parallel systems, single processors can be allocated individually. They are then mapped to the application’s logical structure by the communication mech- anisms. This replaces potentially large external fragmentation by limited internal fragmen- tation, and allows requests from multiple jobs to be interleaved and serviced at the same time. Maintain flexibility One of the reasons for using small fixed chunks is to increase flexibility. Thus to be flexible we should avoid making large fixed allocations. A good example of this principle is the handling of both memory space and disk space. It is possible to allocate a fixed amount of memory for the buffer cache, to support file activity, but this reduces flexibility. It is better to use a flexible scheme in which the memory manager handles file IO based on memory mapped files. This allows for balanced allocations at runtime between the memory activity and file ac- tivity. Likewise, it is possible to allocate a fixed portion of the disk as backing store for paging, but this too reduces flexibility. It is better to do paging into a file, so that additional space can be added by the file system. Again, this allows for more balanced allocations based on acutal usage patterns. 170 Use hierarchies to span multiple sizes In many cases the distribution of request sizes is highly skewed: there are very many small requests, some medium-sized requests, and few very large requests. Thus the operating system should optimize its performance for small requests, but still be able to support large requests efficienty. The solution is to use hierarchical structures that span several binary orders of magnitude. Examples are • The Unix inode structure used to keep maps of file blocks, with its indirect, double indirect, and triple indirect pointers. • Buddy systems used to allocate memory, disk space, or processors. • Multi-level feedback queues, where long jobs receive increasingly longer time quanta at lower priorities. Time is limitless Physical resources are necessarily bounded. For example, there is only so much disk space; when it is used up, nobody can write any more data. But time is limitless. When coupled with the use of small fixed chunks implying preemption, this leads to • The possibility to serve more and more clients, by gracefully degrading the ser- vice each one receives. Examples are time slicing the CPU and sending messages in packets. • The possibility of not having to know about resource requirements in advance in order to make reasonable allocation decisions. If you make a bad decision, you have a chance to correct it in the next round. Avoid running out Running out of a resource at an inopertune moment is worse than cleanly failing a request at the outset. It is best to always have a few instances of each resource at hand, and take measures to renew the supply when it runs low. One example is using hysteresis to dampen oscilations. When a system operates at the end of its tether, it continuously runs out and has to solve this crisis by some quick action. The solution typically provides immediate relief, but does not really solve the basic problem, and the system soon finds itself in the same crisis situation. This is inefficient if the crisis-handling routine is expensive. A better solution is to prepare in advance. When resource availability falls bellow a certain low-water mark, the system initiates an orderly procedure to obtain more. The important point is that this is continued until a higher level of availability is obtained: instead of just getting a bit more than the low-water mark, we achieve a 171 significantly higher high-water mark. This creates breathing room and ensures that the costly resource reclamation procedure is not called again too soon. The problem is of course that sometimes the load on the system indeed needs more resources than are available. The solution in this case is — if possible — to forcefully reduce the load. For example, this is the case when swapping is used to escape from thrashing, or when a system uses admission controls. Define your goals The most common approach to resource management is to strive for “fairness”. This is essentially equivalent to “best effort” and “graceful degradation”. The idea is that the system is not judgmental — it tries to give good service to all, regardless of their standing and behavior. Recently there is more and more emphasis on differentiated services, meaning that different processes or users receive different levels of service. This may be based on administrative considerations, as in fair-share scheduling, or on technical considera- tions, as when trying to meet the real-time needs of multimedia applications. The distinction between these two approaches is important because it dictates the mechanisms that are used. If the goal is to serve all users, then approaches such as partitioning resources into ever smaller portions are justified. But if quality of service is paramount, there is no escape from using admission controls.

8.3 Reduction