All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Jeremy Friesner <jaf@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Anti-memory-fragmentation tricks for my Xenomai process?
Date: Fri, 08 Jul 2011 13:53:25 +0200	[thread overview]
Message-ID: <4E16EFB5.4000700@domain.hid> (raw)
In-Reply-To: <BE293433-495B-4C50-999A-298131FA6D94@domain.hid>

On 07/08/2011 07:48 AM, Jeremy Friesner wrote:
> This all works well, but there is one minor issue where I'd like to
> improve things:  after running for a while, the allocation and
> deallocation of 128kB buffers, interspersed with smaller
> allocations/deallocations, causes fragmentation in the process's
> heap, with the end result that the process appears to be using a lot
> more memory than it actually has allocated.  This doesn't cause real
> problems (AFAICT), but because the GUI for the system has a RAM Usage
> Indicator (that gets its info from /proc/meminfo, and displays total
> memory-usage as a percentage of physical RAM), users are prone to
> wonder why so much RAM is being used even when the program is idle.
> The heap fragmentation makes it look like there is a memory leak,
> even when there technically isn't.

The size allocated by a process is more accurately measured with
/proc/self/maps or /proc/self/smaps than with /proc/meminfo. For the
128k buffers, you can mmap/munmap anonymous memory, this way, you will
only consume what you use. Malloc also has a threshold above which it
uses mmap, maybe you can change that threshold to be 128KiB (I think it
is 4MiB by default). See mallopt documentation.

-- 
					    Gilles.


      parent reply	other threads:[~2011-07-08 11:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-08  5:48 [Xenomai-help] Anti-memory-fragmentation tricks for my Xenomai process? Jeremy Friesner
2011-07-08 10:28 ` Eric Noulard
2011-07-08 11:53 ` Gilles Chanteperdrix [this message]

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=4E16EFB5.4000700@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=jaf@domain.hid \
    --cc=xenomai@xenomai.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.