public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: bwindle-kbt@fint.org
Subject: [Bug 1405] New: Memory leak in VFS?
Date: Wed, 22 Oct 2003 16:36:24 -0700	[thread overview]
Message-ID: <12650000.1066865784@flay> (raw)

http://bugme.osdl.org/show_bug.cgi?id=1405

           Summary: Memory leak in VFS?
    Kernel Version: 2.6.0-test8-bk1
            Status: NEW
          Severity: normal
             Owner: akpm@digeo.com
         Submitter: bwindle-kbt@fint.org


Distribution: Debian Testing
Hardware Environment: SMP, Preempt, i386, SCSI
Software Environment: 
Linux dual266 2.6.0-test8-bk1 #6 SMP Tue Oct 21 11:34:44 EDT 2003 i686 GNU/Linux

Gnu C                  3.3.2
Gnu make               3.80
util-linux             2.12
mount                  2.12
module-init-tools      implemented
e2fsprogs              1.35-WIP
nfs-utils              1.0.5
Linux C Library        2.3.2
Dynamic linker (ldd)   2.3.2
Procps                 3.1.12
Net-tools              1.60
Console-tools          0.2.3
Sh-utils               5.0

Problem Description:
There appears to be a memory leak in the VFS code.  Nikita Danilov
<Nikita@Namesys.COM> posted to the LKML, and I am able to reproduce the
situation. Running fsstress (file system stress tools from XFS ported by Andi
Kleen <ak@suse.de>) on an ext3 filesystem as 

./fsstress -d . -f sync=0 -n 1000000000 -p 111 -v

The kernel begins to use lots of memory in ext3_inode_cache and dentry_cache.
Nikita was able to do this on ext2, and reiser, and I can reproduce it on ext3.
The memory will not release under VM pressure, but does appear to release some
of it if you erase the files created by the fsstress tool. With basically
nothing running, /proc/meminfo is reporting over 50megs Active. The kernel will
not release this memory, despite userspace trying to alloc memory (the alloc'ing
process will instead be killed).  The filesystem is mounted with the default
options (ordered data mode)

There was a change to fs/dcache.c in 2.6.0-test6 that may be responsible.

Steps to reproduce:
run ./fsstress -d . -f sync=0 -n 1000000000 -p 111 -v for a while (an hour or so).


                 reply	other threads:[~2003-10-22 23:36 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=12650000.1066865784@flay \
    --to=mbligh@aracnet.com \
    --cc=bwindle-kbt@fint.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox