Implementing a kernel heap.

[Sourcer]

What is the right approach for kernel heap implementation?

My current idea is something like:
I have 3 layers: Physical mem manager - > virtual mem manager -> kmalloc

kmalloc asks for a physical page, maps it to the kernel's virtual address space, whenever someone asks for more memory(i.e. i already allocated the whole first page), i allocate
another page, map it to the virtual address space... the same process again.

for allocating within a page, i use k&r malloc algorithm

Any better ideas?
Any standard ideas?

[Combuster]

It's pretty standard actually. There are various other malloc implementations out there that supposedly have better properties though.

[Sourcer]

It's pretty standard actually. There are various other malloc implementations out there that supposedly have better properties though.

So no limitations on how much pages my kernel can allocate?

[Combuster]

Think about it, why would you want to impose such a limit?

[Sourcer]

Think about it, why would you want to impose such a limit?

I guess, when you're running on a system that has poor amount of RAM, a kernel that steals memory from userspace programs isn't a good kernel..?

EDIT: but yet again, theres the 'swapping' concept.

[Boris]

Make your kernel efficient, in memory consumption. Dont use a hard design limit.
If you design a memory limit, and if the kernel reaches it, what will you do ? Reboot ?

Nota: all kernels have an implicit limit... because virtual RAM addresses comes in a finite amount.

[gerryg400]

Think about it, why would you want to impose such a limit?

I guess, when you're running on a system that has poor amount of RAM, a kernel that steals memory from userspace programs isn't a good kernel..?

EDIT: but yet again, theres the 'swapping' concept.

Kernels are mostly doing things that userspace asks for. They don't really need their 'own' memory. Basically if a kernel runs out of memory when performing a task for a user it can simply return ENOMEM. It's a good idea though for a kernel to reserve a small amount of memory so that it has the resources to find and kill memory-hogging apps.

[linguofreak]

It's pretty standard actually. There are various other malloc implementations out there that supposedly have better properties though.

So no limitations on how much pages my kernel can allocate?

You're confusing your physical memory manager and your kmalloc. As far as the physical memory manager is concerned *all* allocations it makes are for the kernel. The kernel (specifically the virtual memory manager) may be requesting memory from the physical memory manager in order to satisfy a kmalloc request or a userspace request, but the physical memory manager just knows that it's been asked for a page.

As for limiting how much memory kmalloc can allocate, if kmalloc can't get memory it's very likely the kernel will crash and every userspace process will die, whereas if a userspace allocation fails only that process dies (unless the process is something like your window manager). So you then have to decide which process dies. Some systems just return an allocation failure to userspace and wash their hands of it, which the application could in theory handle and continue running, but in reality almost always results in the application crashing. Linux uses heuristics to try and figure out which process is the least useful to the user for the amount of memory that it's using and end that process, reclaim memory, and return a successful allocation to the process that requested memory. In theory, but not in any system I've ever heard of, you could write an OOM handler that queried the user for a process to kill (but on a server the user might not be present).