Re: malloc memory region descriptors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, Aug 16, 2010 at 4:10 AM, Prabhu nath <gprabhunath@xxxxxxxxx> wrote:


On Mon, Aug 16, 2010 at 1:30 PM, Prabhu nath <gprabhunath@xxxxxxxxx> 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




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux