From: "Abu M. Muttalib" <abum@aftek.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: kernelnewbies@nl.linux.org, linux-newbie@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm <linux-mm@kvack.org>
Subject: RE: Relation between free() and remove_vm_struct()
Date: Thu, 17 Aug 2006 16:57:16 +0530 [thread overview]
Message-ID: <BKEKJNIHLJDCFGDBOHGMEEFBDGAA.abum@aftek.com> (raw)
In-Reply-To: <1155811716.4494.51.camel@laptopd505.fenrus.org>
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>
next prev parent reply other threads:[~2006-08-17 11:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-17 6:59 Abu M. Muttalib
2006-08-17 6:59 ` Arjan van de Ven
2006-08-17 7:56 ` Abu M. Muttalib
2006-08-17 10:48 ` Arjan van de Ven
2006-08-17 11:27 ` Abu M. Muttalib [this message]
2006-08-18 11:43 ` Andy Whitcroft
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BKEKJNIHLJDCFGDBOHGMEEFBDGAA.abum@aftek.com \
--to=abum@aftek.com \
--cc=arjan@infradead.org \
--cc=kernelnewbies@nl.linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-newbie@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox