Paging arrangement ideas
Posted: Mon Sep 09, 2002 3:28 pm
I have decided to try a newish approach to memory management in my OS. I am still using Paging and a Stack-based memory map. Check it:
- If the system has <= 20MBytes of RAM, then create page_dir @ 0x0000, page_tab @ 0x1000, and mem_map @ 0x6000, leaving room for 5 page_tables, and a char mem_map of 5120 elements... Set the memory map to what we know is used... Get free pages from topmost page to lower most page.
- Else, the system has > 20MBytes of RAM. Create the page_dir @ 0x0000, page_tab @ 0x01000000 (16MBytes region), and mem_map @ 0x00100000(1MBytes region). The page_tabs can take a max of 4MBytes of memory (*If your machine has 4GBytes of RAM ), and the mem_map can take 1MByte of RAM(*ditto). Mem_map is setup according to how it's supposed to...
Mem_map: Each page in memory is represented by a single byte in the memory map. 0 = free, 1 = Kernel space, 2 - 65 = Processes using pages...
This is the same as all the usual memory management ideas, except for the fact that the pages tables and the memory maps are placed at totally different places according to the amount of RAM you have. The idea is to have optimum memory conservation.
If memory is available above the 16MByte region, the memory manager should allocate that first. This will leave the memory below 16MBytes to drivers so that they can send buffers to ISA cards (ISA cards cannot address memory above 16MBytes... )
Also, I am using a stack-based memory manager, opposed to a bitmap-based memory manager. Basically the stack-based memory manager uses a single array for the whole memory map. Each byte in the array is for a different location in memory. It can take a max of 1MByte, but only if you have 4GBytes of RAM. You can tell which process is using which area of memory.
In a bitmap-based memory manager, the whole of memory is mapped by individual bits in an array, the max size of 128KBytes. This uses the LEAST amount of memory, but is slower because you need to mask out bits and set indiviual bits. The major reason I didn't use this method is because you cannot find out what is using each page.
CTMEMVIEW.APP
Eventually, I will make a program for my Operating System which will allow the user to view the entire memory map in a similar way that the W32defragment program does. You will be able to scroll down a massive color coded table and select a square. A window will pop-up showing the address name, the program using it, and an option to kill that process and free all blocks relating to it. It will show unfreed blocks relating to killed tasks as a '?'. The user can choose to kill each of these allowing for excellent memory recovery... (No more Windows "You are low on memory!" )
I would like to know what you people think of my idea of creating different page_tables in different areas according to how much memory you have...
- If the system has <= 20MBytes of RAM, then create page_dir @ 0x0000, page_tab @ 0x1000, and mem_map @ 0x6000, leaving room for 5 page_tables, and a char mem_map of 5120 elements... Set the memory map to what we know is used... Get free pages from topmost page to lower most page.
- Else, the system has > 20MBytes of RAM. Create the page_dir @ 0x0000, page_tab @ 0x01000000 (16MBytes region), and mem_map @ 0x00100000(1MBytes region). The page_tabs can take a max of 4MBytes of memory (*If your machine has 4GBytes of RAM ), and the mem_map can take 1MByte of RAM(*ditto). Mem_map is setup according to how it's supposed to...
Mem_map: Each page in memory is represented by a single byte in the memory map. 0 = free, 1 = Kernel space, 2 - 65 = Processes using pages...
This is the same as all the usual memory management ideas, except for the fact that the pages tables and the memory maps are placed at totally different places according to the amount of RAM you have. The idea is to have optimum memory conservation.
If memory is available above the 16MByte region, the memory manager should allocate that first. This will leave the memory below 16MBytes to drivers so that they can send buffers to ISA cards (ISA cards cannot address memory above 16MBytes... )
Also, I am using a stack-based memory manager, opposed to a bitmap-based memory manager. Basically the stack-based memory manager uses a single array for the whole memory map. Each byte in the array is for a different location in memory. It can take a max of 1MByte, but only if you have 4GBytes of RAM. You can tell which process is using which area of memory.
In a bitmap-based memory manager, the whole of memory is mapped by individual bits in an array, the max size of 128KBytes. This uses the LEAST amount of memory, but is slower because you need to mask out bits and set indiviual bits. The major reason I didn't use this method is because you cannot find out what is using each page.
CTMEMVIEW.APP
Eventually, I will make a program for my Operating System which will allow the user to view the entire memory map in a similar way that the W32defragment program does. You will be able to scroll down a massive color coded table and select a square. A window will pop-up showing the address name, the program using it, and an option to kill that process and free all blocks relating to it. It will show unfreed blocks relating to killed tasks as a '?'. The user can choose to kill each of these allowing for excellent memory recovery... (No more Windows "You are low on memory!" )
I would like to know what you people think of my idea of creating different page_tables in different areas according to how much memory you have...