G53OPS - Operating Systems

This course is run at the The University of Nottingham within the School of Computer Science & IT. The course is run by Graham Kendall (EMAIL : gxk@cs.nott.ac.uk)


Introduction to Memory Management

This section is based on (Tanenbaum, 1992), pages 74-81.

One of the main tasks of an operating system is to manage the computers memory. This includes many responsibilities, including

· Being aware of what parts of the memory are in use and which parts are not.
· Allocating memory to processes when they request it and de-allocating memory when a process releases its memory.
· Moving data from memory to disc, when the physical capacity becomes full, and vice versa.

In this handout we consider some ways in which these functions are achieved.

Monoprogramming

If we only allow a single process in memory at a time we can make life simple for ourselves. In addition, if we only allow one process to run at any one time then we can make life very simple.

That is, the processor does not permit multi-programming and only one process is allowed to be in memory at a time. Using this model we do not have to worry about swapping processes out to disc when we run out of memory. Nor do we have to worry about keeping processes separate in memory.

All we have to do is load a process into memory, execute it and then unload it before loading the next process.

However, even this simple scheme has its problems.

· We have not yet considered the data that the program will operate upon.
· We are also assuming that a process is self contained in that it has everything within it that allows it to function. This assumes that it has a driver for each device it needs to communicate with. This is both wasteful and unrealistic. We are also forgetting about the operating system routines. The OS can be considered another process and so we have two processes running which means we have left behind our ideal where we can consider that the memory is only being used by one process.

But, even if a monoprogramming model did not have these memory problems we would still be faced with other problems.

In this day and age monoprograming is unacceptable as multi-programming is not only expected by the users of a computer but it also allows us to make more effective use of the CPU. For example, we can allow a process to use the CPU whilst another process carries out I/O or we can allow two people to run interactive jobs and both receive reasonable response times.

We could allow only a single process in memory at one instance in time and still allow multi-programming. This means that a process, when in a running state, is loaded in memory. When a context switch occurs the process is copied from memory to disc and then another process is loaded into memory.

This method allows us to have a relatively simple memory module in the operating system but still allows multi-programming.

The drawback with the method is the amount of time a context switch takes. If we assume that a quantum is 100ms and a context switch takes 200ms then the CPU spends a disproportionate amount of time switching processes. We could increase the amount of time for a quantum but then the interactive users will receive poor response times as processes will have to wait longer to run.

Last Page Back to Main Index Next Page

 

 


 Last Updated : 23/01/2002