OSDev.org

I am currently reading up on memory management.I have enabled paging.(I am using higher half kernel). Now I have understood that the next step is the low level physical memory manager. There are some parts of thiss that I dont understand and some parts I want to verify my understanding.
1) i have enabled paging , without setting aside any space for a bitmap or a stack. So I suppose that s what i have to do next. For a stack based approach Ill have to set aside some space (unsigned long stack [1MB]) to allocate and free pages.

(This is all physical addresses, i mean no concept of a private address space here right??)
2) Allocation - pop from the stack
3)Deallocation - push into teh stack

4)(This is the part I dont understand ) A memory mapper. To map physical memory to your address space??????. I dont understand that.
I mean in order to enable paging i set aside two global variables , page dir , and page table0 , and filled in entries so that my higher half kerenel is correctly mapped to the actual location. Now for this memory mapper
(I dont understand its purpose fully yet). One suggested technique is to map the last entry of the page directory , to the page directory. Now how does this memory mapper fit into the low level memory manager. I mean isnt the allocation and deallocation of pages through the stack enough, for the low level memory manager. I dont undertand the role of the memory mapper

hanumant wrote:I am currently reading up on memory management.I have enabled paging.(I am using higher half kernel). Now I have understood that the next step is the low level physical memory manager. There are some parts of thiss that I dont understand and some parts I want to verify my understanding.
1) i have enabled paging , without setting aside any space for a bitmap or a stack. So I suppose that s what i have to do next. For a stack based approach Ill have to set aside some space (unsigned long stack [1MB]) to allocate and free pages.

Yes. Based upon whatever approach you are using, you need to set aside a portion of RAM to support it.

hanumant wrote:(This is all physical addresses, i mean no concept of a private address space here right??)
2) Allocation - pop from the stack
3)Deallocation - push into teh stack

Physical Addresses are the direct access to Physical Memory Space. This is the space that exists without any overhead such as paging. When you tell the CPU to fetch from memory location 1234, it uses the address, data and control busses to retrieve such data from RAM, a memory-mapped device... or even "nothing" if there is nothing on the other end of that said address.

hanumant wrote:4)(This is the part I dont understand ) A memory mapper. To map physical memory to your address space??????. I dont understand that.
I mean in order to enable paging i set aside two global variables , page dir , and page table0 , and filled in entries so that my higher half kerenel is correctly mapped to the actual location. Now for this memory mapper
(I dont understand its purpose fully yet). One suggested technique is to map the last entry of the page directory , to the page directory. Now how does this memory mapper fit into the low level memory manager. I mean isnt the allocation and deallocation of pages through the stack enough, for the low level memory manager. I dont undertand the role of the memory mapper

When paging is enabled, you are essentially using "Virtual Memory" at that point. Think of this as nothing more than a customized (hardware enforced) look-up table. Through paging structures such as the Page Directory and Page Tables, you can tell the CPU that Virtual Address 1234 is actually suppose to point to Physical Address 5678.

Mapping the *physical* page directory base address into the last Page Directory entry is a way to access that part of *physical* memory without having to map the *physical* address into the *virtual* memory space each time you'll need it. Essentially, you have a way of access and manipulating the Page Directory and all of the Page Tables no matter where they exist in *physical* memory (RAM.)

Where your Physical Memory Manager comes in, is to satisfy requests from the Virtual Memory Manager. For instance, let's say your program wishes to allocate 16KB of memory. Now, avoiding more efficient techniques for the sake of simplicity, your Virtual Memory Manager would try to find such free room within the Page Tables. Once it finds the space, the Virtual Memory Manager requests RAM (typically in 4KB blocks) from the Physical Memory Manager and inserts the RAM addresses into the Page Table that your Virtual Memory Manager chose for the allocation. For this allocation example, all four of the 4KB RAM chunks returned from the Physical Memory Manager to satisfy the 16KB request could be anywhere in RAM (ideally) but paging and Virtual Memory assure that the 16KB is *virtually* a continuous chunk of memory.
Your virtual memory manager would return the address of 0x0080000 as the base of the 16KB allocation and the program can easily assume that the entire 16KB space is available for use.

With paging and Virtual Memory, you don't need to worry about having to find continuous chunks of physical memory as they can be mapped into virtual addresses. Also, you can have a Page Directory for each process/program which provides basic process protection.

I'm sorry for this bloated and somewhat non-nonsensical reply, but I can't seem to align my thought process right now... sleep time perhaps

HtH, none-the-less

Thanks a lot for your patient explanation. There is one more thing i need to understand. Like you said , mapping the page directory ddress into the last entry helps to access the page directory and modify its contents. However, who is supposed to make that entry?? I mean if the low level memory manager, returns simple pages, then does it make that entry (physical address of the page as the last entry in the page??) , for every page that it returns??? . That doesn't make sense to me. I mean you need to do this only for pages that are going to be used as a page directory.So I suppose it is the responsibility of whoever (VMManager) requests the pages, to distinguish between a page being used as a page directory or other purpose, and also mae that last entry point to the physical address if it is indeed going to be used as a page directory.So that brings me round to the same thing , whats the purpose of doing this mapping in the low level manager if you are not gong to be doing it for every page that you hand out??

hanumant wrote:Thanks a lot for your patient explanation. There is one more thing i need to understand. Like you said , mapping the page directory ddress into the last entry helps to access the page directory and modify its contents. However, who is supposed to make that entry?? I mean if the low level memory manager, returns simple pages, then does it make that entry (physical address of the page as the last entry in the page??) , for every page that it returns??? . That doesn't make sense to me. I mean you need to do this only for pages that are going to be used as a page directory.So I suppose it is the responsibility of whoever (VMManager) requests the pages, to distinguish between a page being used as a page directory or other purpose, and also mae that last entry point to the physical address if it is indeed going to be used as a page directory.So that brings me round to the same thing , whats the purpose of doing this mapping in the low level manager if you are not gong to be doing it for every page that you hand out??

No problem.

You question is the basis of one of those "chicken or the egg" scenarios of OS development. Personally, I take my initial kernel page directory and stick it in that last position before enabling paging. This readily solves such a problem and allows access to the entire 4MB (1024*4KB) worth the Page Tables from 0xFFC00000 to 0xFFFFF000. The last 4KB is going to be a view into the 4KB Page Directory itself. It is somewhat awkward to conceive at first, but if you think about it... as similar to looking at a picture within a picture within a picture ad infinitum... you'll start to understand the usefulness of having the entire run of paging structures available at the cost of sacrificing the last 4MB of Virtual Memory.

I can't quite understand your last sentence, but I will try to explain. You don't have to "map in" your low level memory manager, as it is usually (and absolutely should be) apart of your kernel. Kernel memory space is usually consistent throughout all processes. For example, my kernel memory space is *always* mapped into the last Gigabyte of Virtual Memory... and that remains the same for all processes.

As for keeping track of how the Physical Memory Manager issues out pages, I don't see the need. You may need to make the distinction of the location of RAM being allocated, as with legacy DMA and the such, but the only thing your Physical Memory Manager *needs* to do is "know" if the a portion of memory is free or currently being used. Think of a bitmap representing all of RAM as 4KB chunks/pages. Each bit is either set "0" for Used, or to "1" for Free. This is just a simple example of the concept.

There are many more posts here that have covered this subject better than I. Simply search this forum for "memory management" and read whatever looks applicable... it might take some time to do so... but you'll be glad you did

Hey thanks a lot , I think I have understood.