OSDev.org

Hey all, I've got a few questions on the topic of memory management as I get ready to implement a memory manager in my kernel. I've read all the wiki articles and just need a bit of clarification to as if my understanding is correct.

From what I understand, the memory manager keeps track of blocks of memory that are either allocated or not. So then, does something like "malloc" simply tell the memory manager to allocate "x" bytes of memory? And free does the opposite?

My last question is in regard to stack allocation. I read somewhere on here that stack allocation was the way to go. Is this true?

joshbeitler wrote:From what I understand, the memory manager keeps track of blocks of memory that are either allocated or not. So then, does something like "malloc" simply tell the memory manager to allocate "x" bytes of memory? And free does the opposite?

Basically, yes. You should make a distinction between physical and virtual memory management, if it applies to your OS. We've got articles on both on the wiki.

joshbeitler wrote:My last question is in regard to stack allocation. I read somewhere on here that stack allocation was the way to go. Is this true?

The way to go where?

My last question is in regard to stack allocation. I read somewhere on here that stack allocation was the way to go. Is this true?

Correct me if I'm wrong but I think that you mean a 'stack' structure to hold free pages in your physical memory manager ? If so, that is one way to go.

I recommend that you don't lock your self into something like this too early in your project. You may very well find a requirement later that means you can't use a stack.

Hi,

Split it into 3 different things: physical memory management, virtual memory management and heap. Each of these 3 different things is an abstraction. For each abstraction, research the requirements and design an interface (e.g. a set of function prototypes).

For example; for physical memory management most of the time you only need to be able to allocate or free one physical page without caring much what the physical address of the page is. However, in some cases there are restrictions. For example; for buffers for the old ISA DMA chip you need to be able to allocate contiguous physical pages that don't cross a 64 KiB boundary that are below 0x01000000; and for some other cases (32-bit PCI devices, the PDPT used in PAE, etc) you need to be able to allocate a page that has a 32-bit physical address. There's also various features you might want to support, like NUMA optimisations (allocating a page that is "close"/fast for a specific NUMA domain), page/cache colouring, etc. All of this should be taken into account when designing the interface for the physical memory manager.

Once you've designed the interface, it doesn't matter much how it's implemented (whether you use free page stack/s, or a free page bitmap, or something else, or a mixture of several different methods) because you can easily replace the physical memory manager with something completely different that uses the same interface. This also means that you can skip certain features. For example, your interface might have a function to allocate contiguous physical pages that don't cross a 64 KiB boundary, and your implementation might do nothing more than return an error code for this function; or your interface might have an "allocPhyPage(NUMA_domain, pageColour)" function and your implementation might ignore the NUMA domain and page colour information (which are only really for optimisation) and simply allocate any page.

Basically; the important thing is the design of the interfaces (and being able to replace/improve the implementation later on without breaking everything); and as long as you get that right it shouldn't matter how you implement those interfaces.


Cheers,

Brendan

So for the kernel, what I need to do is physical memory management, correct? Should I create a basic memory manager, and then worry about paging, or develop them together?

So for the kernel, what I need to do is physical memory management, correct? Should I create a basic memory manager, and then worry about paging, or develop them together?

To each his own, really. Many people actually start with paging, then worry about memory management later. It especially happens that way if you have a higherhalf kernel.

Also, there are some concerns that make implementing a strictly separated VMM and PMM a somewhat difficult task to do - because managing the structures for physical memory management means they should be present in virtual memory so that they can actually be modified.

If you can red this, you are too close.

I can't see the individual red pixel components, but my eyes are good enough to read that four feet away.

Ah, that make a lot of sense. Thanks for all the replies, people.