stillconfused wrote:
Hello, I have some questions about my kernel heap, and related things.
Firstly, what should, and shouldn't I be using my kernel heap allocator for?
You should us the heap for anything that cannot be statically sized at compile time.
In older kernels, tables of data structures like all the processes, were statically sized and compiled into the kernel image at build time, making them very difficult to change and tune (basically, at least a small re-compile and relink was required to change any statically sized table.)
Not only that, but the tables would have to be sized for the worst case, wasting memory in the average case.
Instead, just allocate your process structures (and any other dynamic structure) on your heap.
stillconfused wrote:
During the boot process I initialize my kernel heap with a large block of memory, and then use this to allocate memory for all kernel space operations.
I'm writing this kernel for RISC-V, and I don't use a higher-half kernel design. My kernel has a trampoline design like Minix, or XV6 to transfer control between userspace and the kernel. Userspace processes have a stack/heap mapped at arbitrary high addresses, but the kernel stack/heap are identity mapped in kernel space, so that I can easily allocate memory for things like user process page tables, or VirtIO queues where I need a physical address.
The problem with using 1:1 virtual/physical mapping for heap memory is that you have to size and allocate all your heap memory up front, whether you use it or not.
If you instead create your virtual memory space, without backing the memory with physical memory, you can allocate physical memory to your heap on demand.
Otherwise, you're little better off than with statically sized tables.
The other option is to not have a single contiguous heap, but instead use a slab allocator, with each slab sliced into equal sized memory slots. Then, you can new allocate physical pages when you need a new slab, and your heap need not be contiguous.