All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: Pierre Ossman <drzeus@drzeus.cx>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"bugme-daemon@bugzilla.kernel.org"
	<bugme-daemon@bugzilla.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [Bug 12832] New: kernel leaks a lot of memory
Date: Wed, 11 Mar 2009 09:37:40 +0800	[thread overview]
Message-ID: <20090311013739.GA7078@localhost> (raw)
In-Reply-To: <20090310212118.7bf17af6@mjolnir.ossman.eu>

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

On Tue, Mar 10, 2009 at 10:21:18PM +0200, Pierre Ossman wrote:
> On Tue, 10 Mar 2009 21:11:55 +0800
> Wu Fengguang <fengguang.wu@intel.com> wrote:
>
> > If we run eatmem or the following commands to take up free memory,
> > the missing pages will show up :-)
> >
> >         dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024
> >         cp /tmp/s /dev/null
> >
>
> Not here, which now means I've "found" all of my missing 170 MB.
>
> On 2.6.27, when I fill the page cache I still get over 90 MB left in
> "noflags":
>
> 0x20000	     24394       95  _________________n  noflags
>
> The same thing with 2.6.26 almost completely drains it:
>
> 0x20000	      3697       14  _________________n  noflags
>
> Another interesting data point is that those 80 MB always seem to be
> the exact same number of pages every boot.

This 80MB noflags pages together with the below 80MB lru pages are
very close to the missing page numbers :-) Could you run the following
commands on fresh booted 2.6.27 and post the output files? Thank you!

        dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024
        cp /tmp/s /dev/null

        ./page-flags > flags
        ./page-areas =0x20000 > areas-noflags
        ./page-areas =0x00020 > areas-lru

The attached page-areas.c can do the above exact flags matching.

> After that, a comparison shows that this row is in 2.6.27, but not
> 2.6.26:
>
> 0x00020      20576       80  _____l____________  lru
>
> Unfortunately there are about 170 MB of missing memory, not 80. So we
> probably need to dig deeper. But does the above say anything to you?

> I had to remove PG_swapbacked and PG_private2 as 2.6.26/2.6.27 didn't
> have those bits.

Ah sorry! I forgot to switch the tree back to 2.6.27 to run a test.

Thanks,
Fengguang


[-- Attachment #2: page-areas.c --]
[-- Type: text/x-csrc, Size: 3313 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/errno.h>
#include <sys/fcntl.h>

/* copied from kpageflags_read() */
enum {
	KPF_LOCKED,	/*  0 */
	KPF_ERROR,	/*  1 */
	KPF_REFERENCED,	/*  2 */
	KPF_UPTODATE,	/*  3 */
	KPF_DIRTY,	/*  4 */
	KPF_LRU,	/*  5 */
	KPF_ACTIVE,	/*  6 */
	KPF_SLAB,	/*  7 */
	KPF_WRITEBACK,	/*  8 */
	KPF_RECLAIM,	/*  9 */
	KPF_BUDDY,	/* 10 */
	KPF_RESERVED,	/* 11 */
	KPF_SWAPCACHE,	/* 12 */
	KPF_SWAPBACKED,	/* 13 */
        KPF_PRIVATE,    /* 14 */
        KPF_PRIVATE2,   /* 15 */
        KPF_NOPAGE,     /* 16 */
        KPF_NOFLAGS,    /* 17 */
	KPF_NUM
};
#define KPF_BYTES	8

#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

static char *page_flag_names[] = {
	[KPF_LOCKED]		= "L:locked",
	[KPF_ERROR]		= "E:error",
	[KPF_REFERENCED]	= "R:referenced",
	[KPF_UPTODATE]		= "U:uptodate",
	[KPF_DIRTY]		= "D:dirty",
	[KPF_LRU]		= "l:lru",
	[KPF_ACTIVE]		= "A:active",
	[KPF_SLAB]		= "S:slab",
	[KPF_WRITEBACK]		= "W:writeback",
	[KPF_RECLAIM]		= "x:reclaim",
	[KPF_BUDDY]		= "B:buddy",
	[KPF_RESERVED]		= "r:reserved",
	[KPF_SWAPBACKED]	= "b:swapbacked",
	[KPF_SWAPCACHE]		= "c:swapcache",
	[KPF_PRIVATE]		= "P:private",
	[KPF_PRIVATE2]		= "p:private_2",
	[KPF_NOPAGE]		= "N:nopage",
	[KPF_NOFLAGS]		= "n:noflags",
};

static unsigned long page_count[(1 << KPF_NUM)];
static unsigned long nr_pages;
static uint64_t kpageflags[KPF_BYTES * (8<<20)];

char *page_flag_name(uint64_t flags)
{
	int i;
	static char buf[64];

	for (i = 0; i < ARRAY_SIZE(page_flag_names); i++)
		buf[i] = (flags & (1 << i)) ? page_flag_names[i][0] : '_';

	return buf;
}

char *page_flag_longname(uint64_t flags)
{
	int i, n;
	static char buf[1024];

	for (i = 0, n = 0; i < ARRAY_SIZE(page_flag_names); i++)
		if (flags & (1<<i))
		       n += snprintf(buf + n, sizeof(buf) - n, "%s,",
				       page_flag_names[i] + 2);
	if (n)
		n--;
	buf[n] = '\0';

	return buf;
}

static unsigned long pages2kb(unsigned long pages)
{
	return (pages * getpagesize()) >> 10;
}

static void add_index(unsigned long index)
{
	static unsigned long offset, len;

	if (index == offset + len)
		len++;
	else {
		if (len)
			printf("%10lu %8lu %8luKB\n", offset, len, pages2kb(len));
		offset = index;
		len = 1;
	}
}

static void usage(const char *prog)
{
	printf("Usage: %s page_flags\n", prog);
}

int main(int argc, char *argv[])
{
	static char kpageflags_name[] = "/proc/kpageflags";
	unsigned long match_flags, match_exact;
	unsigned long i;
	char *p;
	int fd;

	if (argc < 2) {
		usage(argv[0]);
		exit(1);
	}

	match_exact = 0;
	p = argv[1];
	if (p[0] == '=') {
		match_exact = 1;
		p++;
	}
	match_flags = strtol(p, 0, 16);

	fd = open(kpageflags_name, O_RDONLY);
	if (fd < 0) {
		perror(kpageflags_name);
		exit(1);
	}

	nr_pages = read(fd, kpageflags, sizeof(kpageflags));
	if (nr_pages <= 0) {
		perror(kpageflags_name);
		exit(2);
	}
	if (nr_pages % KPF_BYTES != 0) {
		fprintf(stderr, "%s: partial read: %lu bytes\n",
				argv[0], nr_pages);
		exit(3);
	}
	nr_pages = nr_pages / KPF_BYTES;

	printf("    offset      len         KB\n");
	for (i = 0; i < nr_pages; i++) {
		if (!match_exact && ((kpageflags[i] & match_flags) == match_flags) ||
		    (match_exact && kpageflags[i] == match_flags))
			add_index(i);
	}
	add_index(0);

	return 0;
}

  reply	other threads:[~2009-03-11  1:38 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-12832-27@http.bugzilla.kernel.org/>
2009-03-07 20:24 ` [Bug 12832] New: kernel leaks a lot of memory Andrew Morton
2009-03-07 21:00   ` Pierre Ossman
2009-03-07 22:13     ` Andrew Morton
2009-03-07 22:53       ` Pierre Ossman
2009-03-08 10:00       ` Pierre Ossman
2009-03-08 10:36         ` Pierre Ossman
2009-03-08 12:38           ` Wu Fengguang
2009-03-08 14:26             ` Pierre Ossman
2009-03-08 15:54             ` Pierre Ossman
2009-03-08 19:11               ` Andrew Morton
2009-03-08 19:23                 ` Pierre Ossman
2009-03-07 22:16     ` Andrew Morton
2009-03-09  1:37     ` Wu Fengguang
     [not found]       ` <20090309020701.GA381@localhost>
2009-03-09  7:40         ` Pierre Ossman
2009-03-09 14:22           ` Wu Fengguang
2009-03-09 15:02             ` Pierre Ossman
2009-03-10  2:41               ` Wu Fengguang
2009-03-10  6:56                 ` Pierre Ossman
2009-03-10  8:19                 ` Wu Fengguang
2009-03-10  9:55                   ` Pierre Ossman
2009-03-10 12:22                     ` Wu Fengguang
2009-03-10 13:11                       ` Wu Fengguang
2009-03-10 15:52                         ` Pierre Ossman
2009-03-10 20:21                         ` Pierre Ossman
2009-03-11  1:37                           ` Wu Fengguang [this message]
     [not found]                             ` <20090311075703.35de2488@mjolnir.ossman.eu>
2009-03-11  7:14                               ` Wu Fengguang
2009-03-11  7:26                                 ` Pierre Ossman
2009-03-11  7:36                                   ` Wu Fengguang
2009-03-11  7:57                                     ` Pierre Ossman
2009-03-11  8:20                                       ` Wu Fengguang
2009-03-11 13:05                                         ` Pierre Ossman
2009-03-11 13:00                                       ` Wu Fengguang
2009-03-11 15:02                                         ` Pierre Ossman
2009-03-11 15:47                                           ` Steven Rostedt
2009-03-11 16:46                                             ` Pierre Ossman
2009-03-11 21:43                                               ` Pierre Ossman
2009-03-12  6:50                                                 ` Pierre Ossman
2009-03-12  1:08                                           ` Wu Fengguang
2009-03-12  6:55                                             ` Pierre Ossman
2009-03-12  7:29                                               ` Wu Fengguang
2009-03-11 14:25                                     ` Steven Rostedt
2009-03-11 14:35                                       ` Pierre Ossman
2009-03-11 16:55                                       ` Pierre Ossman
2009-03-11 17:28                                         ` Steven Rostedt
2009-03-11 18:33                                           ` Pierre Ossman
2009-03-11 18:48                                             ` Steven Rostedt
2009-03-11 18:56                                               ` Pierre Ossman
2009-03-11 19:03                                                 ` Steven Rostedt
2009-03-12  2:46                                                   ` KOSAKI Motohiro
2009-03-12  6:53                                                     ` Pierre Ossman
2009-03-10 19:58                       ` Pierre Ossman
2009-03-11  0:19                     ` KOSAKI Motohiro
2009-03-11  7:22                       ` Pierre Ossman

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=20090311013739.GA7078@localhost \
    --to=fengguang.wu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bugme-daemon@bugzilla.kernel.org \
    --cc=drzeus@drzeus.cx \
    --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.