OSDev.org

Hi!

I have been thinking about having a slab allocator in my kernel so that I don't have to use the kernel heap for everything. After some research and thought the plan I came up with is:
1. Split the memory in to different regions
- 0 - 512 MB - low & kernel areas used for PD and PT allocation, modules will be loaded into this region (position independent) and maybe something else (basically, this is page and page-range allocator)
- 512 - 786 MB - slab allocator area used for slab caches, which can be constructed at runtime (the slab allocator would use the heap to keep track of caches and slabs)
- 786 - 1024 MB - kernel heap area
- > 1024 MB - user space (split in its own way, i guess)
2. Set up the heap
3. Create slab caches as needed. This could be specified in a configuration file (cache sizes, total ram available to the allocator and so on) eventually.

But some things are still unclear:
1. Do I actually need 256 MB for the slab caches or could I use 64 MB for instance (or even less, maybe)?
2. Is a 256 MB heap to small? This is one of my main concerns (and #5)
3. How big should an individual cache be (how many objects would I be able to allocate)?
4. Lets say a file handle and a thread handle are the same size. Do I create separate caches and separate allocation functions for the two, or do I use a single cache twice the size?
5. Is the kernel area big enough to hold drivers and modules? Or should I split the kernel area to a kernel area for PDs and PTs and a module area (starting at 128 MB for example), to reduce fragmentation?

Currently, the heap area starts at 512 MB and is 512 MB - 4 kB in size. Everything else is the same.

How do you guys implement your slab allocators and split up your memory? Basically what I want to know is if this design is a solid one and what could be done to improve it.

Thanks,
rJah

rjah,

I don't have drivers or modules in my kernel so my memory layout will be quite different from yours. I can't give you any advice about what you may need.

However, I think you should make your memory layout as configurable as possible. Try to make sure that addresses and sizes are tunable using #defines or even boot-time calculation. It will make your initialisation code a little more complex but will save many rewrites in the future. As your kernel matures you can profile memory usage and modify the memory map.

- gerryg400

gerryg400,
I do plan to make the memory layout configurable at boot-time, but that's a bit away. But first i want to make it work

Thanks,
rJah

rjah,

May I ask, what will be kept in the kernel heap area ?

I don't have a traditional style heap at all. Can't find a use for it in my microkernel.

- gerryg400

gerryg400 wrote:rjah,

May I ask, what will be kept in the kernel heap area ?

I don't have a traditional style heap at all. Can't find a use for it in my microkernel.

- gerryg400

You haven't looked hard enough!

James

gerryg400 wrote: rjah,
May I ask, what will be kept in the kernel heap area ?

All structures the slab allocator needs (lists, nodes, ets.) will be allocated on the heap along with any chunks of memory needed (but not too frequently needed, like GRUB module information and such), for now, later on I moght move some stuff to the slab allocator, or vice-versa.

Do you think a kernel heap brings too much overhead to the system (in terms of memory (headers, footers) and CPU time (algorithm used)). This is of course dependent on my goals, but I would really like to hear your opinion. I have thought about it for a long time and I suppose I could use rawMalloc() (no headers, footers, but no free()) to set things up and rely on the slab allocator from then on but I really like the convenience of having a working heap, so I'll stick with it for at least the next few iterations of the kernel.

rJah

I don't have a traditional style heap at all. Can't find a use for it in my microkernel.

I should clarify that by 'traditional style heap' I meant a general purpose allocator that works like 'user space' malloc/free. I have 3 very simple allocation schemes in the kernel

1. bootalloc - allocates memory that cannot be freed. e.g. kernel stacks, config info, TSS etc.
2. kmalloc/kfree - a sort of slab allocator because I have a reasonably finite set of object sizes. This sits on top of 3.
3. pg_alloc/pg_free - deals in single pages.

This is a microkernel. There is a memory manager in userspace that looks after non-kernel memory.

- gerryg400