OSDev.org

This is how I plan on implementing memory management in my kernel (less=more) for my OS Valix:

Two binary trees make up the kernel heap. One binary tree keeps track of all free memory blocks, sorted by size, so that the smallest one that is just large enough can be selected easily. The other binary tree keeps track of memory that is in use but may be freed later. This second tree is sorted by address instead of size so that the blocks can be easily freed. When a block of memory is allocated, it moves from the first tree to the second. When a block is deallocated, it does just the opposite.

Memory blocks are found by getting the information GRUB provides for us during boot. When a block is allocated, if the block is bigger than needed, it is split up. When there is no block large enough to use, contiguous blocks are joined.

This is done entirely without paging or any sort of virtual memory, it is a physical memory manager. Valix doesn't run userland binaries, so virtual memory is unnecessary: the kernel is the only binary running.

What do you guys think? I've already implemented 90% of this, and it *seems* to work just fine... Is there a way to increase the efficiency? I do plan on using some sort of self-balancing setup later (red-black trees, perhaps?) More importantly, are there any drawbacks?

Does it support aligned blocks?

At the moment, no, but it should be easy to add that. Is there an instance where I might need that?

I know you don't have virtual memory and paging yet, but being able to allocate page-aligned blocks might make life easier later. You might also want to note that some things require an aligned address (to 2, 4, 8 bytes, as an example) including devices and SSE (IIRC).

You've got it backwards I used to have paging and virtual memory, and I've gotten rid of it.

Even so, the remainder of my post is valid.

xvedejas wrote:You've got it backwards I used to have paging and virtual memory, and I've gotten rid of it.

why?

Because I don't (think) I need it... that's why I'm asking opinion...

xvedejas wrote:This is done entirely without paging or any sort of virtual memory, it is a physical memory manager. Valix doesn't run userland binaries, so virtual memory is unnecessary: the kernel is the only binary running.

Then what is the point of the kernel if you don't have anything running? I have a feeling that you will get tired of putting this much effort into a static shell pretty fast. Plus the fact that paging makes a lot of kernel functions easier rather than harder, and is pretty simple to implement (my memory manager is ~80 lines with multiple process support).

NickJohnson wrote:Then what is the point of the kernel if you don't have anything running?

I think he wants the kernel to "run" programs like some kind of interpreter in a managed environment.

Plus the fact that paging makes a lot of kernel functions easier rather than harder...

Like what?

The whole point of a virtual address space is so that two processes can seem to have their own separate memory. In the OP's scenario, he doesn't need any paging. I suspect "Valix" is an attempt to avoid the "dirty work" of a kernel: user-level process switching, paging, system calls, etc.

manonthemoon is quite right.