Relation between free() and remove_vm_struct()

Relation between free() and remove_vm_struct()

[Abu M. Muttalib]

Hi,

In an application I am freeing some memory address, earlier reserved with
malloc.

I have put prints in remove_vm_struct() function in ./mm/mmap.c. For few
calls to free(), there is no corresponding call to remove_vm_struct(). I am
not able to understand why the user space call to free() is not propagated
to kernel, where in the remove_vm_strcut() function should get called.

Please help.

Regards,
Abu.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Relation between free() and remove_vm_struct()

[Arjan van de Ven]

On Thu, 2006-08-17 at 12:29 +0530, Abu M. Muttalib wrote:
> Hi,
> 
> In an application I am freeing some memory address, earlier reserved with
> malloc.
> 
> I have put prints in remove_vm_struct() function in ./mm/mmap.c. For few
> calls to free(), there is no corresponding call to remove_vm_struct(). I am
> not able to understand why the user space call to free() is not propagated
> to kernel, where in the remove_vm_strcut() function should get called.

Hi,
there is 2 parts to this question

first of all, glibc malloc doesn't always use mmap for it's allocations,
it's a split between the brk() area and mmap() depending on the size of
the allocation. (>= 128Kb uses mmap, smaller uses brk(). brk using
allocations will not end up in remove_vm_struct at all)

second of all, glibc delays freeing of some memory (in the brk() area)
to optimize for cases of frequent malloc/free operations, so that it
doesn't have to go to the kernel all the time (and a free would imply a
cross cpu TLB invalidate which is *expensive*, so batching those up is a
really good thing for performance)

I hope this answer helps you... it's probably worth reading the
malloc/malloc.c code in the glibc code tree, this behavior is documented
there...

Greetings,
   Arjan van de Ven

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

RE: Relation between free() and remove_vm_struct()

[Abu M. Muttalib]

Hi Arjan,

Thnax for your reply.

> second of all, glibc delays freeing of some memory (in the brk() area)
> to optimize for cases of frequent malloc/free operations, so that it
> doesn't have to go to the kernel all the time (and a free would imply a
> cross cpu TLB invalidate which is *expensive*, so batching those up is a
> really good thing for performance)

As per my observation, in two scenarios that I have tried, in one scenario I
am able to see the prints from remove_vm_struct(), but in the other
scenario, I don't see any prints from remove_vm_strcut().

My question is, if there is delayed freeing of virtual address space, it
should be the same in both the scenarios, but its not the case, and this
behavior is consistent for my two scenarios, i.e.. in one I am able to see
the kernel prints and in other I am not, respectively.

Note: I am using glib-2.0-arm.

Regards,
Abu.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

RE: Relation between free() and remove_vm_struct()

[Arjan van de Ven]

On Thu, 2006-08-17 at 13:26 +0530, Abu M. Muttalib wrote:
> Hi Arjan,
> 
> Thnax for your reply.
> 
> > second of all, glibc delays freeing of some memory (in the brk() area)
> > to optimize for cases of frequent malloc/free operations, so that it
> > doesn't have to go to the kernel all the time (and a free would imply a
> > cross cpu TLB invalidate which is *expensive*, so batching those up is a
> > really good thing for performance)
> 
> As per my observation, in two scenarios that I have tried, in one scenario I
> am able to see the prints from remove_vm_struct(), but in the other
> scenario, I don't see any prints from remove_vm_strcut().
> 
> My question is, if there is delayed freeing of virtual address space, it
> should be the same in both the scenarios, but its not the case, and this
> behavior is consistent for my two scenarios, i.e.. in one I am able to see
> the kernel prints and in other I am not, respectively.

I'm sorry but you're not providing enough information for me to
understand your follow-on question.

Greetings,
   Arjan van de Ven

> 
-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

RE: Relation between free() and remove_vm_struct()

[Abu M. Muttalib]

Hi,

> > > second of all, glibc delays freeing of some memory (in the brk() area)
> > > to optimize for cases of frequent malloc/free operations, so that it
> > > doesn't have to go to the kernel all the time (and a free would imply
a
> > > cross cpu TLB invalidate which is *expensive*, so batching those up is
a
> > > really good thing for performance)
> >
> > As per my observation, in two scenarios that I have tried, in one
scenario I
> > am able to see the prints from remove_vm_struct(), but in the other
> > scenario, I don't see any prints from remove_vm_strcut().
> >
> > My question is, if there is delayed freeing of virtual address space, it
> > should be the same in both the scenarios, but its not the case, and this
> > behavior is consistent for my two scenarios, i.e.. in one I am able to
see
> > the kernel prints and in other I am not, respectively.
>
> I'm sorry but you're not providing enough information for me to
> understand your follow-on question.

Well, the application, which is causing problem is specific to our
organization and details may not be known to the list. Any ways I am
detailing it further,

Our application is a VoIP application, which uses OSIP stack.

While running the application, when I give outgoing call, I see the VM
getting allocated and subsequently getting freed, this I have verified from
/proc/meminfo and kernel prints (that of remove_vm_struct). But in the case
of incoming call, though this is a reverse case, but I see memory only
getting allocated and not being freed.

I can see in the code that the free function is called but the call has not
been propagated to the kernel. The allocation is in the tune of 4 MB, so the
memory must have been allocated using mmap and not brk, as the heap size for
an application is defined to be 4 K, as per my knowledge. Even if the
allocation is from heap, the heap should get enlarged and on subsequent call
to free, the surplus space should be returned to OS.

Please help.

Regards,
Abu.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Relation between free() and remove_vm_struct()

[Andy Whitcroft]

Abu M. Muttalib wrote:
> Hi,
> 
>>>> second of all, glibc delays freeing of some memory (in the brk() area)
>>>> to optimize for cases of frequent malloc/free operations, so that it
>>>> doesn't have to go to the kernel all the time (and a free would imply
> a
>>>> cross cpu TLB invalidate which is *expensive*, so batching those up is
> a
>>>> really good thing for performance)
>>> As per my observation, in two scenarios that I have tried, in one
> scenario I
>>> am able to see the prints from remove_vm_struct(), but in the other
>>> scenario, I don't see any prints from remove_vm_strcut().
>>>
>>> My question is, if there is delayed freeing of virtual address space, it
>>> should be the same in both the scenarios, but its not the case, and this
>>> behavior is consistent for my two scenarios, i.e.. in one I am able to
> see
>>> the kernel prints and in other I am not, respectively.
>> I'm sorry but you're not providing enough information for me to
>> understand your follow-on question.
> 
> Well, the application, which is causing problem is specific to our
> organization and details may not be known to the list. Any ways I am
> detailing it further,
> 
> Our application is a VoIP application, which uses OSIP stack.
> 
> While running the application, when I give outgoing call, I see the VM
> getting allocated and subsequently getting freed, this I have verified from
> /proc/meminfo and kernel prints (that of remove_vm_struct). But in the case
> of incoming call, though this is a reverse case, but I see memory only
> getting allocated and not being freed.
> 
> I can see in the code that the free function is called but the call has not
> been propagated to the kernel. The allocation is in the tune of 4 MB, so the
> memory must have been allocated using mmap and not brk, as the heap size for
> an application is defined to be 4 K, as per my knowledge. Even if the
> allocation is from heap, the heap should get enlarged and on subsequent call
> to free, the surplus space should be returned to OS.
> 
> Please help.

Can you attach a ptrace to the process in question to see what calls it 
makes, brk, mmap, munmap should be sufficient.  That will allow you to 
determine if the memory is being returned by the libc to the kernel or not.

-apw

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>