My Physical Memory management
Posted: Sat Apr 04, 2009 12:48 pm
Hello everyone. I am currently in the process of designing my operating system.
It's intended to be fast, run on new machines (x86-64), take advantage of new features and get rid of old legacy features. It should be written in C++. The kernel should be as modular as possible, easily portable to new platforms but also it should be easy to replace one design decision with another (such as a stack based allocation with a bitmap or buddy-based one), to switch between them at compile time (or, for some elements, even at runtime). It will probably end up as a microkernel.
Each module should have clean interface, hiding the platform-dependent and implementation-dependent stuff away from rest of the code.
Here's some insight to my physical memory management.
Public Interface of Physical Memory Managers:
/// Initializes the manager, detects memory and creates necessary structures.
bool physicalMemoryManager::initialize();
/// Allocates one physical page and returns it's pointer.
physical_uintptr_t physicalMemoryManager::allocate();
/// Frees a physical page. Page must be the same physical pointer returned by allocate().
bool physicalMemoryManager::free(physical_uintptr_t page);
/// Allocates a continous block of size physical pages, all lower than the under parameter.
physical_uintptr_t physicalMemoryManager::allocateSpecial(physical_size_t size, physical_uintptr_t under);
/// Frees a block of size pages previously allocated by allocateSpecial().
bool physicalMemoryManager::freeSpecial(physical_uintptr_t page, physical_size_t size);
/// Returns number of bytes in one physical page.
physical_size_t physicalMemoryManager::getPageSize()
The Stack Implementation:
First physical page address is stored in a variable, physical_uintptr_t m_firstPage;
When allocate() is called, the first page is temporary mapped into virtual memory somewhere. This free page stores a pointer to next free page, which is then stored in m_firstPage. Now, we unmap the page, and return it.
Free() does the same thing in reverse order. We map the page temporary again, store current top into the soon-to-be-free page, update the first page counter, unmap the page and return true.
AllocateSpecial() is complicated. We should walk the whole stack looking for a continous sequence of physical pages, optionally under some position. Be warned though, this action is really slow and should be avoided! However, it may be required by some legacy device drivers (DMA?). FreeSpecial() does the equivalent of free() on several pages. It's not recommended for device drivers to free once allocated sequence of pages unless they won't ever need it again since the overhead of obtaining these pages again is really huge.
getPageSize() returns the size of one physical page (which is in most, if not all, cases the same as virtual page size, most likely 4K).
And, here are my questions.
Do you think it's a good design? Or would the overhead of mapping the pages temporary, flushing the TLBs, etc be bigger than the overhead caused by searching next free page in a bitmap allocator? Do you have any suggestions on how to improve the design?
Thank you.
It's intended to be fast, run on new machines (x86-64), take advantage of new features and get rid of old legacy features. It should be written in C++. The kernel should be as modular as possible, easily portable to new platforms but also it should be easy to replace one design decision with another (such as a stack based allocation with a bitmap or buddy-based one), to switch between them at compile time (or, for some elements, even at runtime). It will probably end up as a microkernel.
Each module should have clean interface, hiding the platform-dependent and implementation-dependent stuff away from rest of the code.
Here's some insight to my physical memory management.
Public Interface of Physical Memory Managers:
/// Initializes the manager, detects memory and creates necessary structures.
bool physicalMemoryManager::initialize();
/// Allocates one physical page and returns it's pointer.
physical_uintptr_t physicalMemoryManager::allocate();
/// Frees a physical page. Page must be the same physical pointer returned by allocate().
bool physicalMemoryManager::free(physical_uintptr_t page);
/// Allocates a continous block of size physical pages, all lower than the under parameter.
physical_uintptr_t physicalMemoryManager::allocateSpecial(physical_size_t size, physical_uintptr_t under);
/// Frees a block of size pages previously allocated by allocateSpecial().
bool physicalMemoryManager::freeSpecial(physical_uintptr_t page, physical_size_t size);
/// Returns number of bytes in one physical page.
physical_size_t physicalMemoryManager::getPageSize()
The Stack Implementation:
First physical page address is stored in a variable, physical_uintptr_t m_firstPage;
When allocate() is called, the first page is temporary mapped into virtual memory somewhere. This free page stores a pointer to next free page, which is then stored in m_firstPage. Now, we unmap the page, and return it.
Free() does the same thing in reverse order. We map the page temporary again, store current top into the soon-to-be-free page, update the first page counter, unmap the page and return true.
AllocateSpecial() is complicated. We should walk the whole stack looking for a continous sequence of physical pages, optionally under some position. Be warned though, this action is really slow and should be avoided! However, it may be required by some legacy device drivers (DMA?). FreeSpecial() does the equivalent of free() on several pages. It's not recommended for device drivers to free once allocated sequence of pages unless they won't ever need it again since the overhead of obtaining these pages again is really huge.
getPageSize() returns the size of one physical page (which is in most, if not all, cases the same as virtual page size, most likely 4K).
And, here are my questions.
Do you think it's a good design? Or would the overhead of mapping the pages temporary, flushing the TLBs, etc be bigger than the overhead caused by searching next free page in a bitmap allocator? Do you have any suggestions on how to improve the design?
Thank you.