On Mon, Aug 16, 2010 at 4:10 AM, Prabhu nath <[email protected]> wrote:
> > > On Mon, Aug 16, 2010 at 1:30 PM, Prabhu nath <[email protected]>wrote: > >> Dear All, >> >> 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. >> Can you please give me information about how does kernel maintain >> information about memory allocation done by malloc/calloc invoked by a user >> application ? >> >> 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. >> > > I would like to elicit my question. Here is a simple code sample > > int *b; > int main() > { > b = malloc(4); > printf ("Address of b = 0x%08x \n", b); > getchar(); > return 0; > } > > If I pause the program and inspect the maps file </proc/<pid>/maps>, I get > to see a whooping 132K of linear virtual address allocated and Address of b > = 0x0804a008 > Here is a fragment of the maps file. > > 08048000-08049000 r-xp 00000000 fd:00 16845753 cSamples/cTests/a.out > 08049000-0804a000 rw-p 00000000 fd:00 16845753 cSamples/cTests/a.out > *0804a000-0806b000 rw-p 0804a000 00:00 0 [heap]* > b7f3d000-b7f3e000 rw-p b7f3d000 00:00 0 > b7f4a000-b7f4d000 rw-p b7f4a000 00:00 0 > > Suppose if have to extend my code as > c = malloc (34); > d = malloc(12); > e = malloc(1024); > free(e); > f = malloc(1845); > > Assume (c, d, e, f are all declared globally) > > Now, when free(e) is executed, kernel should have some information about > the size of address space allocated to symbol 'e' so that it will only free > that virtual address region in the heap space that was allocated to e. > > Q. Where and how does the kernel maintain information about the size of > address space allocated to symbol 'e' > To be specific, glibc maintains this size information & not the kernel. What exactly happens is, malloc(...) gets the memory from sbrk() or mmap() & whenever user application calls malloc it carves out a region of memory it got from the kernel, slaps a malloc specific header to this region & returns the address immediately after the end of the header, to the user. This header has information about the size of the particular malloc call. So, whenever you call malloc, you potentially waste space for the malloc bookkeeping purposes. Another important observation is that this is reason why we have to pass the address returned by malloc(..), to free(..) & not any other address. O'wise free(..) will fail. free(...) takes in the argument, subtracts the address from the size of the header, looks at the size specified in the header & coalesces it with the free lists available it. Regards, Venkatram Tummala > > > > >> Regards, >> Prabhu >> >> >
