[Solved]Physical Memory Manager & Virtual Memory Manager

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
melgmry0101b
Member
Member
Posts: 109
Joined: Wed Nov 10, 2010 10:49 am

[Solved]Physical Memory Manager & Virtual Memory Manager

Post by melgmry0101b »

Hi everyone,
I am going to develop PMM & VMM for my OS.
I read the documents in the wiki and some tutorials but i think that i didn't understand the main idea.
I want to understand how to make the PMM, the VMM and what is the address spaces.
I read a lot of documents about this but no document described how to develop one , they talk about the allocators and how malloc and free works.
Can anyone explains to me how the PMM and VMM work and what is the address spaces, please?
------------------
Thanks in advance. :)
Last edited by melgmry0101b on Thu Oct 20, 2011 3:19 pm, edited 1 time in total.
User avatar
mark3094
Member
Member
Posts: 164
Joined: Mon Feb 14, 2011 10:32 pm
Location: Australia
Contact:

Re: Physical Memory Manager & Virtual Memory Manager

Post by mark3094 »

Start with a physical memory manager, and get that right before even looking at virtual.

The physical address space is just your physical memory. Each byte of memory has an address, which is why it is called an address space.

A kernel needs to track the memory that is being used. It needs to do this so two different applications or structures (or anything that needs memory) will not try to access the same part of memory. If they do, memory will get overwritten, which will cause bad behaviour.

The Kernel keeps a structure in memory to track what areas of memory have been allocated. Memory is allocated in blocks, rather than in individual bytes. When something needs memory, it makes a request to the Kernel, the Kernel looks up the structure to see what is free, and allocates one or more free blocks as required. It will also make a note that that block of memory is no longer available to be allocated. When the application no longer needs the memory, it informs the Kernel (hopefully) and the Kernel marks it as available once again.

Does that make sense so far?
Casm
Member
Member
Posts: 221
Joined: Sun Oct 17, 2010 2:21 pm
Location: United Kingdom

Re: Physical Memory Manager & Virtual Memory Manager

Post by Casm »

Mozo40 wrote:Hi everyone,
I am going to develop PMM & VMM for my OS.
I read the documents in the wiki and some tutorials but i think that i didn't understand the main idea.
I want to understand how to make the PMM, the VMM and what is the address spaces.
I read a lot of documents about this but no document described how to develop one , they talk about the allocators and how malloc and free works.
Can anyone explains to me how the PMM and VMM work and what is the address spaces, please?
------------------
Thanks in advance. :)
At its simplest, a physical memory manager maintains a bitmap of the memory which is currently being used. At the request of the kernel it will search the bitmap for the required number of contiguos (usually 4096 byte) pages, and then pass their address to the kernel. When the kernel later releases that memory, the physical memory manager will go to the bitmap and mark the pages as available for reuse. Depending upon how much information you want to record, the "bitmap" may or may not have a single bit for each page, indicating it as in use/not in use.

A virtual memory manager is a bit more complicated, but it relies upon the physical memory manager to allocate physical memory, which it then maps to the virtual memory applications work with (although they "think" the addresses they work with refer to physical memory).
User avatar
piranha
Member
Member
Posts: 1391
Joined: Thu Dec 21, 2006 7:42 pm
Location: Unknown. Momentum is pretty certain, however.
Contact:

Re: Physical Memory Manager & Virtual Memory Manager

Post by piranha »

It doesn't have to do it with bitmaps, I actually find a stack to be an easier way of doing it. Anyway. The PMM keeps track of the physical, actual, real memory. It basically keeps track of what sections of memory are being used, and what is free. The implementation of this is however you chose, but it should be able to allocate a page and deallocate a page.

The VMM keeps track of virtual address spaces, and maps pages accordingly. Basically, a bit of code that is running with a certain address space (this is set in a processor register), will try to access a piece of memory. Say 0x80000000. What the processor does (without the knowledge of the code) is to change the address that it accesses from 0x80000000 to whatever that address is mapped to. Say, 0x80000000 -> 0x10000. This means that the physical RAM that is at 0x10000 is being accessed whenever the code accesses 0x80000000. Its abstraction. At its most frustrating.

The way the processor determines what virtual address is what physical address is described in the page directory.

-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
rdos
Member
Member
Posts: 3310
Joined: Wed Oct 01, 2008 1:55 pm

Re: Physical Memory Manager & Virtual Memory Manager

Post by rdos »

The normal procedure is to allocate physical memory on the basis of a 4K page. Almost all allocations can be done on single 4K pages. Therefore, it is overkill to burden the physical memory manager with the ability to allocate larger (or smaller) chunks of physical memory. Some memory-mapped devices will need larger physical memory regions, but those allocations are non-ordinary, and boot-time only, and therefore can cost extra in term of execution speed.

I find linking free pages in a list most convienent. The only problem is that the lists themselves need physical memory.

Virtual memory allocation could be divided into the needs of kernel (ring zero devices) and applications. I have a page-aligned and a dword aligned memory allocator for kernel. The paged aligned allocator would scan page-tables for free pages. The dword-aligned allocator links memory blocks much like traditional MS-DOS blocks or C-library heap implementations. Applications have their own executable-format related allocators. PE format has a page-based allocator operating on page-tables, with the C library providing smaller blocks.
gerryg400
Member
Member
Posts: 1801
Joined: Thu Mar 25, 2010 11:26 pm
Location: Melbourne, Australia

Re: Physical Memory Manager & Virtual Memory Manager

Post by gerryg400 »

pitfall wrote:2. from e820 table, I can allocate pages (but cannot deallocate), this is used by the kernel during system bootstrap to build "wired" structures (will never be freed). This includes a "phypage_map" that works like a LIFO stack. I may improve this design for multi-page allocation....
I also have a boot allocator that allocates directly from the PMM's copy of the E820 table. I understand that you cannot free memory back to the bootallocator but if you set things up correctly you can free it to the 'real' allocator later. In fact I initialise my allocator by calling kphys_free() for every page that's left after boot. My PMM is just a linked list.

Like RDOS said you should heavily optimise for allocating 1 page at a time and freeing pages many at a time.
If a trainstation is where trains stop, what is a workstation ?
melgmry0101b
Member
Member
Posts: 109
Joined: Wed Nov 10, 2010 10:49 am

Re: Physical Memory Manager & Virtual Memory Manager

Post by melgmry0101b »

Thank you very much for all your replies :)
Post Reply