Physical memory management?

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
mariuszp
Member
Member
Posts: 587
Joined: Sat Oct 16, 2010 3:38 pm

Physical memory management?

Post by mariuszp »

Hello.

My OS uses a very simple physical memory allocator: basically, it has a "placement frame", which is the lowest unsued frame, and is initialized at the 2MB mark. When a frame is freed, it pushes it onto a stack; and frames from the stacked are all popped on requests before the next placement frame is returned.

My problem is this: how do I know I don't accidentally allocate a frame which belongs to some memory-mapped device? Obviously I can't rely on drivers to tell me that, because to load them, I need to allocate memory in the first place.

I've heard that GRUB (or other multiboot-compliant bootloaders) can give me a 'memory map'. Is this what gives me all the necessary information to ensure I don't allocate a frame that belongs to a device? If not, how does your OS do it?

Thank you for help.
User avatar
JAAman
Member
Member
Posts: 879
Joined: Wed Oct 27, 2004 11:00 pm
Location: WA

Re: Physical memory management?

Post by JAAman »

mariuszp wrote:Hello.

My OS uses a very simple physical memory allocator: basically, it has a "placement frame", which is the lowest unsued frame, and is initialized at the 2MB mark. When a frame is freed, it pushes it onto a stack; and frames from the stacked are all popped on requests before the next placement frame is returned.

My problem is this: how do I know I don't accidentally allocate a frame which belongs to some memory-mapped device?
because a memory mapped device doesn't respond to memory addresses belonging to "free ram"
I've heard that GRUB (or other multiboot-compliant bootloaders) can give me a 'memory map'. Is this what gives me all the necessary information to ensure I don't allocate a frame that belongs to a device? If not, how does your OS do it?
yes, basically

note that there is no reason to assume that your memory is in order in a single place, for instance, you might have memory from 0-2MB then nothing from 2MB-6MB then more memory from 6MB-7MB then nothing from 7MB-26MB then more memory from 26MB-3GB then nothing form 3GB-7GB then more memory from 7GB-18GB then nothing from 18GB-129GB then more memory... etc. so its not just "devices" you need to worry about, you need to be sure there is actually memory (and not nothing) at that address

whatever bootloader you are using (whether it is GRUB, or a proper one you make yourself) will get memory information from the firmware (the method will change for different firmware, but your bootloader will know how to get it for whatever system you booted from) and turn that information into some kind of table or "map" of memory, which describes all memory, and pass that to your physical memory manager (note that the "memory map" GRUB gives you is simply copied from the firmware, and includes duplicate spaces (memory mapped multiple times), fragments (single large section of available memory might be listed as several smaller segments) and is not sorted in any kind of order... none of these things should be in the memory map your bootloader gives to the physical memory manager initialization

from this map, you need to create a list of available memory frames -- the simplest implementation on x86 you simply make a list of 4k-aligned blocks of 4k memory (discard anything not 4k aligned or smaller than 4k, and break larger blocks into 4k blocks) -- now you have a list of physical pages, if you did this correctly, all these blocks will be valid memory, none point to void, none point to non-memory devices, none point to memory that is used by the firmware, etc. -- this is your list of valid frames of physical memory, and can be allocated at any time here (note this is the simplest, not the best, implementation)
Post Reply