OSDev.org

----
This thread is referenced by the FAQ
----

I'm still trying to get my head around all the MM stuff, I have a few questions :).

This is what I need to do, from what I understand (not in order):

1. I need to setup a page directory (probably at the end of my kernel?) and set up the page directory entries.

2. I need some assembly functions to load the page directory address into cr3, and set some bit in cr0.

3. I need to use a bitmap, stack or linked list approach to be able to tell if pages are used or not.

4. I need an allocator to mark pages as used and give the addresses to whoever requested it.

5. I need a deallocator (reverse allocation process).

6. I need a mapper that will map virtual pages to physical ones (page frames) ???. Still pretty confused here.

Can anybody correct me where I'm wrong?

Now this is where I'm really confused...

Is all what i've mentioned above for managing memory in kernel space? What about user space? Are you supposed to setup page tables or something for all of the physical memory? I don't really get this part at all... I'm probably babbling about nothing :-\

I still have other questions but I'll wait and see if they get answered, if I get replys to this.

first, feel invited to check the quick linkz section.

second, Tim Robinson has written a text about Memory Management, which should give you some hold to get a grip on the topic.

now your questions:
1. Yes, you need a page duirectory and yes, you need page tables and yes, you need page table entries. Best is, you map PG Dir to itself (at index 0x3ff) and with this locate it to adress 0xfffff000 of the virtual adress space.

2. Yes.

3. correct. 4. correct. 5. correct.

6. No need to get confused: you map Physical Pages to Virtual ones. Your physical page allocator hands out 4 kb pages at request. It's straight forward.

your last question: It is also for user processes: all you need to do is add som algorithms for building a process adress space. The Memory Manager doesn't hand out malloc sized memory chunks. It deals with pages and with adress spaces.

and no, don't set up pagetables for ALL physical memory: hand out physical memory at needs upon page fault: the memory in question isn't valid, but the process has the right to get it: fetch a physical page of 4 kb and enter it at the appropriate place in the process adress space. this is a Per Page directory operation in my opinion.

For your physical memory: ask the Bios, how much of it is installed. Then calculate, how much it is in KB; these KB's you divide by Page size and know now, how many Pages you have at hands to deal with. Then set up a stack or Bitmap or what so ever which represents your physical memory. Hand out memroy pages at request or take them back.

HtH

Thanks, BI Lazy, that cleared some stuff up.

Btw, I did read Tim's tutorials, they helped alot. I'm going to read them again, though.

I still have a few questions :-\

How much memory will one page directory map? Am I supposed to loop throught the page directory and set the proper bits (ie not-present) in the beginning, then add page tables when needed? Also, for mapping. Do you hand the mapper a virtual and physical address, then it makes the proper PTE's?

chris wrote:How much memory will one page directory map?

All of it -- the whole 4GB virtual address space. To get multiple address spaces, switch page directories.

Am I supposed to loop throught the page directory and set the proper bits (ie not-present) in the beginning, then add page tables when needed?

Yes, although it's enough to zero the whole page directory, because the present/nonpresent bit is 1=present, 0=not present. Note that if the present bit is not set, the MMU won't look at the other bits.

Also, for mapping. Do you hand the mapper a virtual and physical address, then it makes the proper PTE's?

No, you have to assemble the PDEs and PTEs yourself.

@Tim: Correct me if I'm wrong but I think you said before that you used linked list(s) to manage memory. Is there anything you say for those? I plan on using them myself. Do you use more than one (i.e. one for holes and one for processes, described in Tanenbaum's book)?

Thank you for your previous reply.

Mobius currently uses three linked lists to manage physical memory pages: free, free below 1MB, and zero. The memory for each item in these lists comes from an array of all physical pages in the system. This way, you can quickly grab, say, the next available zero page; but you can also look up a particular page given the address.

The zero page list is there because there is a zero page thread running in the background. Normal allocations come from the zero page list. The zero page thread grabs pages from the free list, clears (zeroes) them, and adds them to the zero list.

How do you form an array with all physical addresses and how is it indexed?

You find a region of memory big enough to hold one element for each physical page in the system. It's indexed by page number, i.e. (physical address) / PAGE_SIZE.

Unfortunately, the problem comes in allocating this array before the memory manager has been initialised.

Thanks for all your help. I'm going to be starting my MM soon, and I'll probably need some more :P

..

Last edited by Perica on Sun Dec 03, 2006 9:28 pm, edited 1 time in total.

I think he means, once a page has been allocated the zero thread zero's it and sticks it in the zero list. It takes all it's page from the free one.



???

..

Last edited by Perica on Sun Dec 03, 2006 9:28 pm, edited 1 time in total.

I reckon they get zeroed out for having memory at hands which is in a clear, well defined state in order to avoid weird things happening.

I'm not sure why you'd need to (or want to) zero pages at all before mapping them into a processes' address space, though ?

what if deallocated memory happens to contain some sensitive data? (from another process or the operating system)

zloba: That's exactly right. Can't have one process freeing a page which contains sensitive information and another allocating that same page again. (The first process wouldn't even need to explicitly free the page, if the physical page had been freed while paging to disk.)

In any case, zeroing all memory at startup would take ages. Better to have a low-priority thread doing it in the background. It doesn't matter how many zeroed pages there are available as long as there enough to satisfy allocation requests.