On Mon, Aug 16, 2010 at 1:00 AM, Prabhu nath <gprabhunath@xxxxxxxxx> wrote:
*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.
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
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
