OSDev.org

I already have paging switched on and working before I jump into the C kernel. I have the first 4MB identity mapped, and I also have the 4MB starting at 2GB mapped to the physical first 4MB (in other words, 2 page tables pointing to the same physical space).

Now I plan to start writing the memory management stuff, and want to make sure I understand the theory behind it. From reading around, I'm starting to understand that there are (roughly) three levels of management that need to be done for applications to work.

• Physical memory manager. This allocates and frees physical memory in units of the page size (typically 4kB). It must keep track of memory that it has already allocated, and that that has been freed, and will at least include a function to allocate and one to free blocks of memory. The functionality it supplies will only ever be used by the virtual memory manager (the next "level").
• Virtual memory manager. This will use the physical memory manager to allocate/free physical frames in order to create and manage the page directory (of which there may be more than one) and the tables it contains. This also only works in units of 4kB (or whatever the page size is).
• Heap memory manager. This makes use of the virtual memory manager to grab free memory (of any size), creating new tables/directories if necessary, and clean up later. This is typically left to the applications themselves, and isn't done in the kernel (e.g. malloc(), new(), etc. in application code).

I understand that there are many ways to make each of these "levels" of management work, but first I'd like to know if I'm thinking about the general structure in the correct way. Can anyone comment on what I have written so far? Is it correct to think about three different "levels"? If I implement the first two properly (the physical and virtual memory managers), then am I finished with memory management until I come to multitasking?

Lastly, although I said that heap memory management is left to the applications, I take it that there is one application in particular where it is my responsibility: the kernel itself! Is this true?

Thanks for taking the time to read this, and apologies for cramming so many questions into my first post.

Basically, yes, there are 3 levels of mm as you described. There are however perhaps more than one manager at each level.

For example a system may have a single physical memory manager but perhaps 2 quite distinct virtual memory managers (one for the kernel itself that manages kernel space and one that manages the various user-spaces) and many heap memory managers (malloc in user-space, perhaps some form of managed heap with garbage collection also in user space and buddy and slab allocators both in kernel space).

There are others required too outside of this structure. Having a boot allocator can simplify the boot process.

smolloy wrote:[*]Virtual memory manager. This will use the physical memory manager to allocate/free physical frames in order to create and manage the page directory (of which there may be more than one) and the tables it contains. This also only works in units of 4kB (or whatever the page size is).

I think you have the basics well understood. Just a few perhaps misunderstandings with your bullets. The page table live its own life in the kernel and is just a "tool" for mapping virtual space. Managing the page table itself should be done separately from the levels of memory management, this is important since page tables varies depending architecture. Virtual memory manager tracks the virtual space and allocates and frees that one, much like the physical memory manager. Maybe that is what you meant from the beginning?

OSwhatever wrote:Managing the page table itself should be done separately from the levels of memory management, this is important since page tables varies depending architecture. Virtual memory manager tracks the virtual space and allocates and frees that one, much like the physical memory manager. Maybe that is what you meant from the beginning?

Thanks for the clarification. I had the virtual memory management and page management tangled together in my head, but I see how it is cleaner to keep those functions separate, so thanks for pointing that out.

I'm starting to understand that I simplified a little too much in my first post. I had been thinking that the heap management (outside of the kernel) was not my responsibility, but a little bit of extra reading leads me to believe that I at least need to provide sbrk() and brk() at that level.

Thanks to both of you for your time.

smolloy wrote:I'm starting to understand that I simplified a little too much in my first post. I had been thinking that the heap management (outside of the kernel) was not my responsibility, but a little bit of extra reading leads me to believe that I at least need to provide sbrk() and brk() at that level.

You do if your OS is meant to be a *nix, but nothing says it has to be.

smolloy wrote:

• Virtual memory manager. This will use the physical memory manager to allocate/free physical frames in order to create and manage the page directory (of which there may be more than one) and the tables it contains. This also only works in units of 4kB (or whatever the page size is).

VMM manage address space, it may map device memory which is not allocated from PMM.
VMM may also link with useful features like CoW and swap memory.

OK, I understand. Thanks for correcting me.

I think I have a pretty good understanding of what I need to do next, so thanks to everyone who took the time to reply.

smolloy wrote:

OSwhatever wrote:Managing the page table itself should be done separately from the levels of memory management, this is important since page tables varies depending architecture. Virtual memory manager tracks the virtual space and allocates and frees that one, much like the physical memory manager. Maybe that is what you meant from the beginning?

Thanks for the clarification. I had the virtual memory management and page management tangled together in my head, but I see how it is cleaner to keep those functions separate, so thanks for pointing that out.

I'm starting to understand that I simplified a little too much in my first post. I had been thinking that the heap management (outside of the kernel) was not my responsibility, but a little bit of extra reading leads me to believe that I at least need to provide sbrk() and brk() at that level.

Thanks to both of you for your time.

I wouldn't get torn up on nomenclature. For example, I use "virtual memory management" to mean "the stuff that handles virtual memory" - i.e. page structures, TLB invalidation etc. Mapping and unmapping, essentially.

OSwhatever is right however in that no matter the nomenclature you should separate out the "thing that carves up the available (virtual) address space for use" and "the thing that manages V->P mappings".