Date: Sun, 23 Jan 2005 02:32:48 -0800
From: Andrew Morton <akpm@osdl.org>
To: Jens Axboe <axboe@suse.de>
Cc: alexn@dsv.su.se, kas@fi.muni.cz, linux-kernel@vger.kernel.org
Subject: Re: Memory leak in 2.6.11-rc1?
Message-Id: <20050123023248.263daca9.akpm@osdl.org>
In-Reply-To: <20050123095608.GD16648@suse.de>
References: <20050121161959.GO3922@fi.muni.cz>
	<1106360639.15804.1.camel@boxen>
	<20050123091154.GC16648@suse.de>
	<20050123011918.295db8e8.akpm@osdl.org>
	<20050123095608.GD16648@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1079
Lines: 27

Jens Axboe <axboe@suse.de> wrote:
>
> But I'm still stuck with all of my ram gone after a
>  600MB fillmem, half of it is just in swap.

Well.  Half of it has gone so far ;)

> 
>  Attaching meminfo and sysrq-m after fillmem.

(I meant a really big fillmem: a couple of 2GB ones.  Not to worry.)

It's not in slab and the pagecache and anonymous memory stuff seems to be
working OK.  So it has to be something else, which does a bare
__alloc_pages().  Low-level block stuff, networking, arch code, perhaps.

I don't think I've ever really seen code to diagnose this.

A simplistic approach would be to add eight or so ulongs into struct page,
populate them with builtin_return_address(0...7) at allocation time, then
modify sysrq-m to walk mem_map[] printing it all out for pages which have
page_count() > 0.  That'd find the culprit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/