linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Chris Friesen" <cfriesen@nortel.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Rik van Riel <riel@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, Balbir Singh <balbir@linux.vnet.ibm.com>
Subject: Re: tracking memory usage/leak in "inactive" field in /proc/meminfo?
Date: Wed, 10 Feb 2010 11:05:16 -0600	[thread overview]
Message-ID: <4B72E74C.9040001@nortel.com> (raw)
In-Reply-To: <20100210093140.12D9.A69D9226@jp.fujitsu.com>

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]

On 02/09/2010 06:32 PM, KOSAKI Motohiro wrote:

> can you please post your /proc/meminfo?


On 02/09/2010 09:50 PM, Balbir Singh wrote:
> Do you have swap enabled? Can you help with the OOM killed dmesg log?
> Does the situation get better after OOM killing.


On 02/09/2010 10:09 PM, KOSAKI Motohiro wrote:

> Chris, 2.6.27 is a bit old. plese test it on latest kernel. and please
don't use
> any proprietary drivers.


Thanks for the replies.

Swap is enabled in the kernel, but there is no swap configured.  ipcs
shows little consumption there.

The test load relies on a number of kernel modifications, making it
difficult to use newer kernels. (This is an embedded system.)  There are
no closed-source drivers loaded, though there are some that are not in
vanilla kernels.  I haven't yet tried to reproduce the problem with a
minimal load--I've been more focused on trying to understand what's
going on in the code first.  It's on my list to try though.

Here are some /proc/meminfo outputs from a test run where we
artificially chewed most of the free memory to try and force the oom
killer to fire sooner (otherwise it takes days for the problem to trigger).

It's spaced with tabs so I'm not sure if it'll stay aligned.  The first
row is the sample number.  All the HugePages entries were 0.  The
DirectMap entries were constant. SwapTotal/SwapFree/SwapCached were 0,
as were Writeback/NFS_Unstable/Bounce/WritebackTmp.

Samples were taken 10 minutes apart.  Between samples 49 and 50 the
oom-killer fired.

		13		49		50
MemTotal	4042848		4042848		4042848
MemFree		113512		52668		69536
Buffers		20		24		76
Cached		1285588		1287456		1295128
Active		2883224		3369440		2850172
Inactive	913756		487944		990152
Dirty		36		216		252
AnonPages	2274756		2305448		2279216
Mapped		10804		12772		15760
Slab		62324		62568		63608
SReclaimable	24092		23912		24848
SUnreclaim	38232		38656		38760
PageTables	11960		12144		11848
CommitLimit	2021424		2021424		2021424
Committed_AS	12666508	12745200	7700484
VmallocUsed	23256		23256		23256

It's hard to get a good picture from just a few samples, so I've
attached an ooffice spreadsheet showing three separate runs.  The
samples above are from sheet 3 in the document.

In those spreadsheets I notice that
memfree+active+inactive+slab+pagetables is basically a constant.
However, if I don't use active+inactive then I can't make the numbers
add up.  And the difference between active+inactive and
buffers+cached+anonpages+dirty+mapped+pagetables+vmallocused grows
almost monotonically.

Thanks,

Chris

[-- Attachment #2: meminfo.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 76528 bytes --]

  parent reply	other threads:[~2010-02-10 17:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-09 16:51 Chris Friesen
2010-02-10  0:32 ` KOSAKI Motohiro
2010-02-10  3:50   ` Balbir Singh
2010-02-10  4:09     ` KOSAKI Motohiro
2010-02-10 17:05   ` Chris Friesen [this message]
2010-02-11  0:45     ` Minchan Kim
2010-02-11 18:54       ` Chris Friesen
2010-02-11 19:04         ` Rik van Riel
2010-02-12  2:38         ` Minchan Kim
2010-02-12  7:35           ` Chris Friesen
2010-02-12  8:04             ` KOSAKI Motohiro
2010-02-15 15:50             ` Chris Friesen
2010-02-15 17:00               ` Rik van Riel
2010-02-16 16:52                 ` Chris Friesen
2010-02-16 17:12                   ` Rik van Riel
2010-02-16 21:26                     ` Chris Friesen
2010-02-16 22:22                       ` Rik van Riel
2010-02-18 15:39                         ` tracking memory usage/leak in "inactive" field in /proc/meminfo? -- solved Chris Friesen
2010-02-12 17:50           ` tracking memory usage/leak in "inactive" field in /proc/meminfo? Catalin Marinas
2010-02-13  6:29     ` Balbir Singh
2010-02-15 16:02       ` Chris Friesen

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=4B72E74C.9040001@nortel.com \
    --to=cfriesen@nortel.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@redhat.com \
    /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