Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I've been reading through a few of the old memory management posts trying to get a handle on exactly what is(should be) going on. Am I right in thinking that the Kenel itself should need Malloc and Malloc is only really appropriate for User space programs?
I have paging set up at the moment so that once the Kernel loads a single page is created in the directory of 4kb. Am I meant to just use this for the Kernel's own memory allocations and if so how do I track an allocate space within that page without the Malloc helper function? In short I think I'm lost... help please
there are usually two things: malloc, a user-level library function that allows user program to manage their heap with little intervention from the kernel kmalloc, a kernel-internal function that provides a malloc-like feature to the kernel.
malloc is usually built on top of a system call like "sbrk" -- that instructs the kernel that the program is now bigger -- and virtual memory management (which automatically adds/swaps pages as required).
kmalloc typically operate on the "kernel heap" which covers a pre-allocated portion of the virtual address space and may be using the same kind of virtual memory management, but as there's less overhead in modifying mappings, kmalloc can also be more "aggressive" in the way it releases pages when blocks of memory are kfree'd.
In addition, the kernel usually comes with other flavours of memory allocations such as slabs of buffers, pools of list cells and the like, where allocation/deallocation occurs at such a rate than generic "malloc"-like managers.
Page tables & directories typically directly allocates memory from the physical memory manager, a special kind of "pool".
When you say that kmalloc works on the pre-allocated kernel heap does this then mean that kmalloc cannot (typically) dynamically request new pages? Or come to that do we work the kernel heap outwith the paging directory?
It would appear kmalloc is really what I'm interested in at the moment, standard malloc as part of the C library sounds like it would be better to use something like Doug Lea's version there.
elaverick wrote:
When you say that kmalloc works on the pre-allocated kernel heap does this then mean that kmalloc cannot (typically) dynamically request new pages? Or come to that do we work the kernel heap outwith the paging directory?
Up to you. What makes kmalloc() different from malloc() is that malloc() keeps some kind of "free memory buffer" so that it does not have to call sbrk() (or MORECORE() or brk() or mmap() or whatever system function can provide it with more heap memory) on every allocation.
kmalloc(), because it already is a kernel-space function, has access to all the internals of the kernel. Many calls that would be prohibitively expensive for user-space malloc() are cheap for kmalloc(). You could also add additional parameters to kmalloc() to request specific types of memory, while malloc() has a defined parameter list and return value.
It would appear kmalloc is really what I'm interested in at the moment, standard malloc as part of the C library sounds like it would be better to use something like Doug Lea's version there.
Exactly.
Every good solution is obvious once you've found it.
elaverick wrote:
When you say that kmalloc works on the pre-allocated kernel heap does this then mean that kmalloc cannot (typically) dynamically request new pages? Or come to that do we work the kernel heap outwith the paging directory?
What i mean is that you will usually organize your virtual kernel space something like:
[tt]
+-----------------+
| code, data, bss |
| all your kernel |
| bits. |
+-----------------+
###################
+-PGALN-----------+
| pg directory |
| system page tbl |
| |
+-----------------+
| kernel heap |
| |
| |
| |
+-----------------+
###################
###################
## other objects ##
## allocated in ##
## kernel space ##
## (buffers, etc.##
###################
###################
[/tt]
Which means you may, for instance, define _kernel_heap_start_vaddr and _kernel_heap_end_vaddr right in your linker script and then use those address to initialize the kernel heap's internals.
Now, you may very well decide (and that what i decided in Clicker) that when a block of memory on the kernel heap is unallocated, then the corresponding physical memory could be used for something else, including for mapping user-level stuff.
That is, when you release a chunk of memory in the kernel heap, you also release frames the chunk was based on -- but only if those frames are _fully contained_ in the chunk that has been released.
