On Mon, Aug 16, 2010 at 1:00 AM, Prabhu nath <gprabhun...@gmail.com> wrote:
> Dear All,
>
*I understand that kernel maintains a descriptor (*vm_area_struct*) per
application to hold information about the virtual address space allocated
for
the heap region.*
Not entirely true. the linux kernel does not necessarily maintain a single
vm_area_struct for the heap region per application. it depends on whether
user space glibc malloc code is configured to use only sbrk(...), only
mmap(...) or both sbrk(...) & mmap(...). Recent versions of glibc malloc
code uses both sbrk(...) & mmap(...) to get memory from the kernel. If only
sbrk(...) is used, there will be only one vm_area_struct for the heap. If
mmap(...) is also used, you could potentially end up with multiple
vm_area_structs because sbrk(...) guarantees that heap will be virtually
contiguous because it extends or decreases the heap but mmap(...) does not
guarantee this behavior. A vm_area_struct holds information about virtually
contiguous area having similar attributes such as access permissions etc.
>
> In linux kernel, for all memory allocation done by *vmalloc*,
> kernel maintains memory region descriptor *(vm_struct)* which stores
> information about the linear virtual address range, no. of physical page
> frames allocated... as a linked list headed by *vmlist *symbol.
>
Correct. But vmalloc(...) has nothing do with user space memory. It is used
for dynamic kernel modules & some device drivers. So, it is exclusively
related to the kernel & not user space.
Can you please give me information about how does kernel maintain
> information about memory allocation done by malloc/calloc invoked by a user
> application ?
>
malloc/calloc code is user space library call (glibc) which in turn calls
mmap(...) or sbrk(...) or both as i explained above. So, the very first time
malloc is invoked by the user application with a size of say 16 bytes for
example, malloc(..) will call sbrk(..) or mmap(...) with a much larger size
than 16 bytes so that the next time malloc is called with another 50 bytes
for example, it won't have to call mmap(...) or sbrk(...) again. So,
malloc(...) gets a large chunk of memory from the kernel & manages that
memory by splicing and coalescing memory as & when application asks for more
memory from malloc. As sbrk(...) only extends or decreases the existing
heap, only one vm_area_struct is operated upon by the kernel in this case.
But if malloc(...) calls mmap(...), it may result in another
vm_area_struct(...)
So, the bottom line is, vmalloc(...) is not related to user space
malloc/calloc call in any way & the kernel maintains information about
malloc/calloc memory allocation in (possibly multiple) vm_area_structs. if
you call mmap(...) directly from the application, it could possibly result
in a vm_area_struct in the kernel just like malloc(...) calling mmap(...)
will result in a vm_area_struct in the kernel.
Hope this helps.
Regards,
Venkatram Tummala
>
>
>
> Regards,
> Prabhu
>
>
