linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: "Abu M. Muttalib" <abum@aftek.com>
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 08:59:25 +0200	[thread overview]
Message-ID: <1155797966.4494.29.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <BKEKJNIHLJDCFGDBOHGMKEEHDGAA.abum@aftek.com>

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>

  reply	other threads:[~2006-08-17  6:59 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 [this message]
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
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=1155797966.4494.29.camel@laptopd505.fenrus.org \
    --to=arjan@infradead.org \
    --cc=abum@aftek.com \
    --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