Page 1 of 1
paging: where to store memory blocks
Posted: Fri Dec 27, 2013 9:07 pm
by shael
hello:
I am using grub to boot up my kernel. I am working on paging and have hit a sort of chicken/egg issue. My thought was that it would take more space, but I could use a stack of free pages that I could use to pull off when I wanted a free page. I was going to iterate through the memory map and add all free pages to that stack, but I am unsure where would be a good place to store this. How have people handled this in the past? it is before paging is set up, because I want to have this information when I set up paging so I am able to add these pages.
Thanks,
Re: paging: where to store memory blocks
Posted: Fri Dec 27, 2013 9:45 pm
by PearOs
shael wrote:hello:
I am using grub to boot up my kernel. I am working on paging and have hit a sort of chicken/egg issue. My thought was that it would take more space, but I could use a stack of free pages that I could use to pull off when I wanted a free page. I was going to iterate through the memory map and add all free pages to that stack, but I am unsure where would be a good place to store this. How have people handled this in the past? it is before paging is set up, because I want to have this information when I set up paging so I am able to add these pages.
Thanks,
Well I know in my 64bit Kernel I ran into a similar issue. My solution was to create an array of Page Table Entrys that lied within the code, set them up and then enable paging and then once I was ready grow to the full 4Gb in my system. I'm not sure if that's exactly what your going for, but there's an idea.
- Matt
Re: paging: where to store memory blocks
Posted: Fri Dec 27, 2013 10:35 pm
by mateuszb
On a modern UEFI system, you can get a complete memory map and memory ranges along with their types. You can then find a memory region that is eligible for being used by the OS and of large enough size to accommodate a stack of free pages. You can put your stack of free pages there and then use that stack to bootstrap your higher level allocator.
Re: paging: where to store memory blocks
Posted: Sun Dec 29, 2013 4:25 pm
by shael
hello:
thanks for the info. I think I can find a memory mapped location and just start my stack there, then start adding the rest of the pages. It's just a bit hard to figure out where to begin--it's sort of a chicken egg issue.
I had one final question. Do people usually tend to move their kernels up? Is there a way to figure out what address your kernel starts at and where it ends? I had something like this in my linker script, but it doesn't seem to do much good. Maybe just the size and the loaded address of the kernel would be good. I'm sorry for the newbish questions, but any info would be awesome.
Thanks,
Re: paging: where to store memory blocks
Posted: Mon Dec 30, 2013 3:19 pm
by bluemoon
shael wrote:hello:
I am using grub to boot up my kernel. I am working on paging and have hit a sort of chicken/egg issue. My thought was that it would take more space, but I could use a stack of free pages that I could use to pull off when I wanted a free page. I was going to iterate through the memory map and add all free pages to that stack, but I am unsure where would be a good place to store this. How have people handled this in the past? it is before paging is set up, because I want to have this information when I set up paging so I am able to add these pages.
Thanks,
I reserved 4K memory from the BSS for the "free page stack", then loop the memory map and push pages onto the stack.
When the stack cross the 4K boundary it trigger page fault, and fetch a page from the stack, which already have 512 items.
Re: paging: where to store memory blocks
Posted: Sun Jan 12, 2014 8:31 am
by gusc
I'd like to drop my question here by the means of similarity. I have a similar chicken/egg problem with pages already set up in my own bootloader. I've id-mapped the first 2MB of memory and it's quite enough to grow further. I don't have a free page stack. I've left the first MB of memory as is, then I have all the id-mapped page tables starting at 1MB boundary and I have a heap after that up to 2MB boundary. So when a page fault occurs when my heap allocator runs out of memory I've already run out of free pages and I've no where to create a new page table. That means that I've to keep track if there is at least one page left to create a page table (or even 3 pages, if I need to create 2nd and 3rd level tables too).
So the questions are:
1. Is it a smart move to use identity mapping in your kernel/bootloader, or is there any other allocation mechanism that's more suitable (like free lists in heap allocator or this page stack you're talking about)?
2. Should I map all of the RAM at the beginning or leave it as is with an extensible mechanism, that maps new pages on the fly?
Thanks in advance!