OSDev.org

My kernel's memory manager is a mess and I've decided to redo it properly. I'm worried that I had the wrong idea about how memory is supposed to work and I built it horribly because of that. Now, obviously the implementation of this stuff in my kernel is subjective, and I'm not looking for someone to tell me a specific algorithm (what would be the fun in that?) but I want to make sure I understand the general process I should look implement.

My first question:
What is the difference (if there is one) between kmalloc and the physical memory manager? The way I understand it, the physical memory manager hands out 4KiB 'pages', and kmalloc divys the pages up into smaller sections so the kernel can request, for example a 4 int array by using kmalloc(4*sizeof(int)). Kmalloc then looks at the 'pages' it has to work with and then sees if it needs more space, at which point it asks the physical memory manager to give it the next page. Basically, my current implementation is that kmalloc is just malloc for kernel-specific memory. Is my understanding of this process correct?

Where does paging come into this? I understand that it enables memory protection and lets you address pages in a different order than they are physically, but when I enable paging, should I go through with my physical memory manager and set up the page tables so that all the pages I have to work with are contiguous when addressed virtually through paging? The pages in which my kernel exists, however, should be 'identity mapped' (am I using that term correctly?) such that addressing it physically and addressing it virtually both work the same, correct?

Where does userspace come into all of this? Should I set up all my page tables to belong to the kernel and then change them as programs request memory? Should malloc rely on the physical memory manager, or some other process?

Thanks

Hi,

Sanchezman wrote:My first question:
What is the difference (if there is one) between kmalloc and the physical memory manager?

Normally; the physical memory manager allocates and frees physical pages, the virtual memory manger "manages" how physical pages (and other things - e.g. files and swap space) are mapped into virtual address spaces, and kmalloc divides up the virtual pages for the kernel (just like "malloc()" or "new" or a garbage collector or whatever would do for a process).

Sanchezman wrote:Where does paging come into this? I understand that it enables memory protection and lets you address pages in a different order than they are physically, but when I enable paging, should I go through with my physical memory manager and set up the page tables so that all the pages I have to work with are contiguous when addressed virtually through paging?

Initialisation depends on how you feel like doing it. Some people use fixed physical pages to setup paging, and then initialise their physical memory manager after that. Other people initialise their physical memory manager and then allocate pages needed to setup paging. I go one step further, and initialise a simple physical memory manager and setup initial paging in the boot loader.

Sanchezman wrote:The pages in which my kernel exists, however, should be 'identity mapped' (am I using that term correctly?) such that addressing it physically and addressing it virtually both work the same, correct?

In general; no. You might temporarily identity map (while enabling paging), but that's almost always temporary and once the kernel is ready it'd discard that identity mapping. For example (for a 32-bit OS) you might identity map 16 MiB, then map the kernel to 0xC0000000 (so it's out of the way), then discard the identity mapping.

Sanchezman wrote:Where does userspace come into all of this? Should I set up all my page tables to belong to the kernel and then change them as programs request memory? Should malloc rely on the physical memory manager, or some other process?

User-space typically begins at (or near) 0x00000000 (where the identity mapping was before it was discarded). Normally each process has its own separate virtual address space, and pages are mapped into that virtual address space "as needed". This includes when the executable is first being loaded (e.g. and your loader is putting different parts of the executable file in different parts of the virtual address space, and creating an initial stack, etc). Typically "something" (e.g. the C library if the process was written in C, the Java virtual machine if its a Java process, etc) does whatever is appropriate for that language (which may or may not be "malloc()") and relies on the kernel's virtual memory manager to get more virtual pages and free existing virtual pages (where the kernel's virtual memory manager takes care of asking the kernel's physical memory manager to allocate or free physical pages if/when necessary).


Cheers,

Brendan