OSDev.org

I have a question that confuses me a lot. I know what heap is, that is not my problem. What are the key differences between VMM and PMM? Is paging VMM or PMM (I think VMM)?
Can you show me an example where I would have to use them. What are the key functions I need to implement within them?

How about a small homeworkish research?

Already done, I just can't find anything that I would personally need. Where ever I look there is a different implementation, one guy puts paging in PMM one in VMM, etc...

PMM and VMM in this case refer to "Physical Memory Manager" and "Virtual Memory Manager", and (from my understanding) they're each responsible for managing their respective address spaces at the page level. For example, the physical memory manager manages the physical address space, which includes handing out and managing physical pages, and possibly other physical memory management responsibilities like swapping out pages and optimising the location of data in memory. The virtual memory manager, on the other hand, manages the virtual address space, of which usually there's one per process (but not always). This involves stuff like mapping in program code and data, and mapping in files and other things to be read by the application.

Note however, that they're not set in stone, that's just my understanding of what people mean when they say PMM and VMM. It depends from kernel to kernel what parts do what actions, especially in microkernels, where parts of (or most of) the memory managers may be implemented in userspace. Perhaps an expert could give you a more formal definition? As others have mentioned, they're just terms, and actual implementation details are left up to you. For example, even if your VMM handles mapping, there might be paging stuff involved in both the PMM and VMM (especially if the PMM handles stuff like swapping or optimisation).

- Mikumiku747

If you don't need a feature, you don't need a feature.
If you don't know whether you need a feature, it's time to study up. Open up any decent book on operating systems and read the chapters dedicated to memory management and related things. That may give you some ideas why you may need a feature. However, you may still not need it, but at least it will be an informed decision. Right now you're uninformed.

I know most of that, read it online. That is about what I know in general when it comes to PMM/VMM theory. I just don't need swapping and stuff nor I will be implementing it. What are those functions that is what I am asking.

I know exactly what I need, I don't want to implement some random function for no reason.
My question is what are those other commonly used functions inside VMM and PMM that are like allocate page and free page.

I use PMM for allocating physical pages only (RAM management in other words). It's called by my kalloc() and VMM routines.

And in my VMM I've the following:
1. allocating and mapping bss memory for user threads
2. IDT points here, as the page fault handler is a VMM routine for me
3. I'm not planning to implement brk() and sbrk() system calls, but if I was, I would put them here.

That's all. My malloc(), calloc() and free() implementations will be purely in user space once I'll implement them, and they will rely on the functionality provided by VMM.

Nuno may have been contagious.

Hi,



Physical memory manager is primarily "allocate_one_physical_page()" and "free_one_physical_page()". It might have less frequently used variations (that are mostly only needed for device drivers) to allocate multiple physical pages, possibly with various restrictions (e.g. "must have 32-bit physical address"), and possibly with "cache-ability controls". It might support things like large pages, and NUMA optimisations, and cache/page colouring, and maybe even hot-plug RAM and ECC "corrected/uncorrected" error reporting. It can also be used to manage the whole physical address space, including the ability to keep track of which areas of the physical memory map are used for memory mapped devices, and including being responsible for managing MTRRs.

Virtual memory management is about creating an illusion - the illusion of multiple separate address spaces. "Virtual" means the same as it does in "virtual machine". Historically, virtual memory and processes come from the idea of using a computer to emulate multiple (virtual) computers, where each process has one (or more) virtual CPUs (threads) and its own virtual address space. To create the illusion, the virtual memory manager typically uses paging to map "things" into the virtual address space (and control permissions, etc). Things that are mapped into the virtual address include physical memory (obtained from the physical memory manager), and swap space, and files, and whatever else. It also includes trickery to reduce (physical) memory consumption, like various "copy on write" tricks. You can think of it as some function/s to create and destroy virtual address spaces; plus keeping track of the "virtual type" of areas within a virtual address space (e.g. if an area is supposed to behave like it's RAM, or not); plus whatever is necessary to make areas behave according to how their virtual type says they should even when (e.g.) the actual type of a page is nothing like the virtual type (e.g. when a virtual page is supposed to behave like RAM, but it's actually been sent to swap space and isn't RAM at all).

The result of the virtual memory manager is that a process has its own address space (that might be 3 GiB, and could be part of larger address space that the process needn't know about) and it can do whatever it likes with its virtual address space (or at least, it can do whatever kernel lets it do).

Note that this gets us to the boundary between "OS" and "language". A programming language isn't just a language, it's a specification for (yet another) abstract machine. For example, for the C abstract machine there is no stack, no registers, no flags, no instructions and no interrupts/exceptions (but there is variables and statements and functions and signals).

At the boundary between OS and language there's "mystical voodoo" to make the language's abstract machine work as a process. This mystical voodoo includes compilers, libraries, etc; and it can also include virtualisation (e.g. Java's virtual machine). For C, "malloc()" and "free()" are part of the mystical voodoo that makes C's abstract machine work as a process. For C++ and Java "new" and "delete" are part of the mystical voodoo that makes their abstract machines work. The mystical voodoo for a language is designed to match the OS (and designed to use the kernel's API, and virtual memory manager that the kernel provides).


Cheers,

Brendan

That is something I have no use of at the moment. Looks like I don't need a VMM for now.

Thank you so much!! This is the answer I was looking for. Now I know what to look for and also code. Actually I have never used any sort of a virtual address space mechanism. I need to do some research on that topic to fill all the theoretical gaps I have.