All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chris Friesen" <cfriesen@nortel.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: /proc/<pid>/maps question....why aren't adjacent memory chunks merged?
Date: Thu, 13 May 2010 15:34:04 -0600	[thread overview]
Message-ID: <4BEC704C.9000709@nortel.com> (raw)

Hi,

I've got a system running a somewhat-modified 2.6.27 on 64-bit x86.

While investigating a userspace memory leak issue I noticed that
/proc/<pid>/maps showed a bunch of adjacent anonymous memory chunks with
identical permissions:

7fd048000000-7fd04c000000 rw-p 00000000 00:00 0
7fd04c000000-7fd050000000 rw-p 00000000 00:00 0
7fd050000000-7fd054000000 rw-p 00000000 00:00 0
7fd054000000-7fd058000000 rw-p 00000000 00:00 0
7fd058000000-7fd05c000000 rw-p 00000000 00:00 0
7fd05c000000-7fd060000000 rw-p 00000000 00:00 0
7fd060000000-7fd064000000 rw-p 00000000 00:00 0
7fd064000000-7fd068000000 rw-p 00000000 00:00 0
7fd068000000-7fd06c000000 rw-p 00000000 00:00 0
7fd06c000000-7fd070000000 rw-p 00000000 00:00 0
7fd070000000-7fd074000000 rw-p 00000000 00:00 0
7fd074000000-7fd078000000 rw-p 00000000 00:00 0
7fd078000000-7fd07c000000 rw-p 00000000 00:00 0
7fd07c000000-7fd07fffe000 rw-p 00000000 00:00 0

I was under the impression that the kernel would merge areas together in
this circumstance.  Does anyone have an idea about what's going on here?

Thanks,

Chris

WARNING: multiple messages have this Message-ID (diff)
From: "Chris Friesen" <cfriesen@nortel.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: /proc/<pid>/maps question....why aren't adjacent memory chunks merged?
Date: Thu, 13 May 2010 15:34:04 -0600	[thread overview]
Message-ID: <4BEC704C.9000709@nortel.com> (raw)

Hi,

I've got a system running a somewhat-modified 2.6.27 on 64-bit x86.

While investigating a userspace memory leak issue I noticed that
/proc/<pid>/maps showed a bunch of adjacent anonymous memory chunks with
identical permissions:

7fd048000000-7fd04c000000 rw-p 00000000 00:00 0
7fd04c000000-7fd050000000 rw-p 00000000 00:00 0
7fd050000000-7fd054000000 rw-p 00000000 00:00 0
7fd054000000-7fd058000000 rw-p 00000000 00:00 0
7fd058000000-7fd05c000000 rw-p 00000000 00:00 0
7fd05c000000-7fd060000000 rw-p 00000000 00:00 0
7fd060000000-7fd064000000 rw-p 00000000 00:00 0
7fd064000000-7fd068000000 rw-p 00000000 00:00 0
7fd068000000-7fd06c000000 rw-p 00000000 00:00 0
7fd06c000000-7fd070000000 rw-p 00000000 00:00 0
7fd070000000-7fd074000000 rw-p 00000000 00:00 0
7fd074000000-7fd078000000 rw-p 00000000 00:00 0
7fd078000000-7fd07c000000 rw-p 00000000 00:00 0
7fd07c000000-7fd07fffe000 rw-p 00000000 00:00 0

I was under the impression that the kernel would merge areas together in
this circumstance.  Does anyone have an idea about what's going on here?

Thanks,

Chris

--
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:[~2010-05-13 21:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-13 21:34 Chris Friesen [this message]
2010-05-13 21:34 ` /proc/<pid>/maps question....why aren't adjacent memory chunks merged? Chris Friesen
2010-05-14  6:27 ` Américo Wang
2010-05-14  6:27   ` Américo Wang

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=4BEC704C.9000709@nortel.com \
    --to=cfriesen@nortel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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.