Memory Management

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
dc0d32

Memory Management

Post by dc0d32 »

hi

   i have just started paging. in the memory management, i am having some problems.

the very first thing : i have to keep track of all the pages in the usable/allocatable area, like to which process it is allocated, it's referance count [for swapping].

i can think of some ways to do so.

1. make a page allocation bitmap. every time, scan the entire bitmap [for the free page if allocating and for that occupied page when freeing]. i would never prefer this.

2. make a page allocation "array" of the foll. struct.

Code: Select all

/*
the page object
We maintain a pool[DLL] of free pages, and a pool
of the page_t[DLL] for each task. hence, the need of searching
a page in the allocation bitmap will virtually be eliminated.
it only needs to be searched in the pool of that specific task.
*/
typedef struct TAGpage_t{
   bit32u      pid;   //PID of owner task
   /*there is no need to keep a "allocated" flag, since the pid=0
   doesn't point to any process*/
   
   bool      allocatable_to_user;   //whether can be allocated to user tasks
   bit32u      phys_page_number;   //the physical page number

   struct TAGpage_t   *prev, *next;   //pointers for the linked list

   /*other fields can be added as needed*/
}page_t;
   the size of this array is determined at runtime [when kernel is just starting] depending on how many allocatable pages are there in the system memory. now, we can create a linked list of the page objects that will represent free pages, another one for the pages allocated to kernel, and one linked list for each task. please note that in this case, even though we are going for a dynamic data structure, we do not need a dynamic memory manager [which, if it would, create the famous "chicken and Egg" problem]. The array works as a dynamic store for the nodes, the only difference is that all the nodes are pre-allocated. the nodes [representing a page] will keep on wandering from one linked list to another [eg. pool of task's pages to pool of free pages, then to another task's pool].
   the bitmap occupies nearly 4-5MB to keep track of 1GB memory.[not of major concern though]

   for now, i have made it as a doubly linked list, i can [and will] reduce it to singly linked list.

   problem with this, as we say, is the waste of time in traversing the linked list.


3. if we can create linked lists using static storage, we can also create BST or AVL trees[maybe heap?] which will save much of time for searching the pages, specially those ones which are allocated to some task and task wants to free it.

   if i select any of these, how do i tackle shared pages/memory?
   
   i find third one interesting. if anyone has tried it, or has read about it, please tell me.


   one more thing, haven't started thinking about it, but in what way do you implement a kernel/task heap manager once the thing above is up? [ie. the basic functionality of page allocation - deallocation syscalls provided.]

   thanx.
FlashBurn

Re:Memory Management

Post by FlashBurn »

I use a bitmap as lowest physical memory manager. And to keep track of all 4KiB pgs this only needs 128KiB space and 256Bytes for 2 4MiB pgs bitmaps - one for keeping track of the free 4MiB pgs and one for keeping track of the 4MiB pgs where are >= 1 free 4KiB pgs - This thing is fast and it uses not so much memory. Then I have a stack allocator on top of this, one for 4KiB pgs and one for 4MiB pgs.

There should be a tutorial about the bitmap allocator on Bonafide I think!
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:Memory Management

Post by Pype.Clicker »

well, i got somehow the feeling that you're still in some fog about physical memory management. Of course, having a pool per process (or per task or per thread or whatever) will have to figure out what's available quicker. However, i'm not sure your suggested structure is the best:

1. you can have the pool linked to a "process" structure, which means it's not useful to have the owner's pid repeated for every page: your page is owned by the process that points to the list, period.

2. you allocate and free _pages_, so why not use a whole page to store as much frame numbers as you can (probably 1000 and a few) and create a linked list of _pages_ rather than a linked list of smaller cells ? that wouldn't waste any memory since only _free_ memory is used to store information about free memory.

3. afaik, there's no real need to be able to tell "is physical frame xyz available ?", so the only real use for a bitmap allocator is that it can help figuring "where can y find N contiguous physical pages that are free ?".

Finally, you may like our FAQ page about MM algorithms ...
Post Reply