Memory management

[paulbarker]

I have written a paper about my ideas for memory management in my Xarnos operating system and put it up on my website:

http://eternalseptember.co.uk/files/Memory.pdf

It explains the physical memory manager i have implemented, and the basics for a virtual memory manager. If you're interested, please take a look and let me know. (it's in PDF format, other formats can be put up on request).

The license is currently just an "All rights reserved" until I decide what is more appropriate. Please get in touch if you are interested in doing anything with the paper.

Cheers,
Paul Barker

[Pype.Clicker]

you may want to google for that "Slab allocator" document (it should be pointed by the FAQ too). Slabs are _really_ useful for kernel development ...

[paulbarker]

Got and read it. I'll take another look because I didn't quite get all the details with that first read (over a year ago, I can hardly remember anything from it).

A slab allocator may be a good idea for the kernel, but this VMR system is going to be used for both kernel and user mode, with the kernel-specific stuff on top. Maybe a slab system could work like that?

I'll have a read and decide where to go.

EDIT: I've had a skim over the paper, and I think theres a nice boundary here. VMRs are used to get the pages, and slabs are used to manage data structures in those pages. So VMRs could be the backend for a slab allocator. Also, slabs are no use for things like stacks, memory mapped files and that where the data has no structure which the kernel understands.

Cheers,
Paul

[Pype.Clicker]

indeed. the slab is mainly a replacement for kmalloc in most places. when i say it's a nice thing to think about early is that, with clicker, i first went for a generic "kalloc" subsystem and then tried to have "slabs" on top of that, but mixing the two means that when you want a 4KB-wide slot of data for a slab (and you want it 4KB-aligned too, for reasons internal to clicker's "slabs"), you end up with 4K+xx bytes allocated, meaning that you have a collection of pages that quickly become unusable for the slab ... not so nice.

[paulbarker]

Just finished re-reading the slab paper.

I think for the moment I'm going to stick to a simple kalloc() system based on bget (public domain sequential allocator). I can replace this with a caching system such as the slab allocator later, and kalloc() calls will just use that as a backend, as described in the slab paper. After that, different subsystems can be migrated to the slab system.

The VMR system I described does not handle any of the actual mapping of virtual pages to physical pages, it just handles allocation of virtual addresses. The real design work to do now is in that area (for example how to maintain page tables).

I'm planning to work on a 3 pass development model of my own invention:

1) Get it working.
2) Make it work well.
3) Make it work fast.

I name it "common sense".