Memory Management (Again)

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
Sum Dude

Memory Management (Again)

Post by Sum Dude »

This question might seem stupid but...

Could somebody please describe to me,
the exact function(s) of a low level
memory manager.

Thanx in advance
Schol-R-LEA

RE:Memory Management (Again)

Post by Schol-R-LEA »

>On 2002-04-10 16:48:59, Sum Dude wrote:
>This question might seem stupid but...
>
>Could somebody please describe to me,
>the exact function(s) of a low level
>memory manager.
>
>Thanx in advance

The *exact* functions are going to depend on the design. However, generally speaking, it has to:

1) Keep track of the physical memory usage, usually by means of an allocation map or table 9the 'free list'). This must be kept up to date at all times.
2) Implement a policy on how memory units will be allocated and when they will be deallocated.
3) Provide a means for allocating and deallocating memory for both new and existing processes.
4) Handle system-dependent memory details (i.e., the locations of ROM or other sacred memory locations, the setting up of LDTs, manipulation of segments and/or pages, etc.)
5) Remap logical or virtual memory to physical memory locations, if supported.
6) Handle exceptional cases - in particular, exhaustion of available memory - gracefully.

1 and 2 are the most important of these, while 3 is just the interface to 2's functionality. Any good book on OS design should cover these in detail, usually emphasizing the importance of an efficient allocation algorithm. The major alocation algorithms are First Fit (allocate the first block of available memory large enough to meet the request), Best Fit (allocate the block closest in size to the request), and Worst Fit (allocated the largest available block no matter what). Oddly enough, Worst Fit generally gives the best results, as it minimizes fragmentation (the tendency of memory to end up broken into many small blocks, making it impossible to allocate larger blocks even when enough meory is available) and is easy to implement efficiently as a linked list of blocks going from largest to smallest.

At this point, this post is becoming a tutorial in its own right; my best suggestion is to pick up a good book on OS design or three and read through them. One reasonably good one, "An Operating Systems Vade Mecum", is available online as PS, PDF or plain text; see http://nondot.org/sabre/os/files/Misc/
for details, as well as some pointers to other references; if your feeling brave, the author's home page (http://cs.engr.uky.edu/~raphael/) has another copy, as well as some links to more advanced work in the area. Some more likns are:

http://g.oswego.edu/dl/html/malloc.html - review of a simple memory allocator

http://cdsmith.twu.net/professional/osdesign/ch05.html - a part of an OS tutorial, "The Common Man's Guide to OS Design"

Note that some, but not all, of these issues also apply to disk management, though that has other factors which make it more complicated.

Finally, keep in mind that this is the *low-level* allocator; the user level (and even jernel level) memory management should be in a higher abstraction layer, except in the case of an exokernel design.
Post Reply