public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Frederic Giasson <fgiasson@mediatrix.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Memory leak problem with JFFS2
Date: Wed, 31 Jul 2002 16:17:16 +0100	[thread overview]
Message-ID: <23196.1028128636@redhat.com> (raw)
In-Reply-To: <2702075D4DE2B043BF5EB82E9CFAD45B0BD37A@mail1.mediatrix.com>

fgiasson@mediatrix.com said:
>  I took some time to track down the memory leak that happens after
> umount. First I compiled JFFS2 as a module and loaded/unloaded it
> doing a mount/umount in between.  No BUG occured, meaning that no slab
> object is still allocated when I unload the module.  Then I
> investigated around the kmalloc/kfree, but I found nothing.  I put
> traces and counters each time a kmalloc / kfree was called, and the
> number of kmalloc and kfree is balanced. Therefore, I can conclude
> than the memory leak is not an allocated object still allocated at
> umount time and is not a kmalloc without kfree neither. Do you have
> any other idea about it?  This is not very likely to be the mount /
> umount mechanism that could cause the leak, I tried mounting and
> unmounting NFS and the memory usage before and after does not change. 

Can you remind me what you have to do to reproduce this?

With 2.5.29, which contains the latest JFFS2 code from CVS...

# vmstat ; while true ; do mount -t jffs2 mtd0 /mnt/spare ; sync ; umount /mnt/spare ; vmstat|tail -1 ; done
   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 0  0  0      0  81800      0  26244   0   0     2     5 1003     8   2   3  95
 1  0  0      0  81696      0  26244   0   0     2     5 1003     8   2   3  95
 1  0  0      0  81700      0  26244   0   0     2     5 1003     9   2   3  95
 1  0  0      0  81712      0  26244   0   0     2     5 1003     9   2   3  95
 1  0  0      0  81696      0  26244   0   0     2     5 1003     9   2   3  95
 2  0  0      0  81704      0  26244   0   0     2     5 1003     9   2   3  95
 2  0  0      0  81708      0  26248   0   0     2     5 1003     9   2   3  95
 2  0  0      0  81696      0  26248   0   0     2     5 1003    10   2   3  95
 2  0  0      0  81696      0  26248   0   0     2     5 1003    10   2   3  95
 2  0  0      0  81712      0  26248   0   0     2     5 1003    10   2   3  95
 2  0  1      0  81688      0  26248   0   0     2     5 1003    10   2   3  95
 2  0  1      0  81696      0  26248   0   0     2     5 1003    10   2   3  95
 2  0  0      0  81708      0  26248   0   0     2     5 1003    10   2   3  95
 2  0  0      0  81692      0  26248   0   0     2     5 1003    10   2   3  95
 2  0  0      0  81696      0  26248   0   0     2     5 1003    10   2   3  95
 2  0  0      0  81708      0  26248   0   0     2     5 1003    10   2   3  95
 2  0  0      0  81692      0  26248   0   0     2     5 1003    10   2   3  95
 2  0  0      0  81696      0  26248   0   0     2     5 1003    11   2   3  95
 2  0  0      0  81708      0  26248   0   0     2     5 1003    11   2   3  95
 2  0  0      0  81680      0  26248   0   0     2     5 1003    11   2   3  95
 2  0  0      0  81724      0  26248   0   0     2     5 1003    11   2   3  95
 2  0  0      0  81712      0  26248   0   0     2     5 1003    11   2   3  95
 2  0  0      0  81704      0  26248   0   0     2     5 1003    11   2   3  95
 2  0  0      0  81696      0  26248   0   0     2     5 1003    11   2   3  95
 2  0  1      0  81708      0  26248   0   0     2     5 1003    11   2   3  95
 2  0  0      0  81688      0  26248   0   0     2     5 1003    11   2   3  95
 2  0  0      0  81696      0  26248   0   0     2     5 1003    11   2   3  95
 2  0  0      0  81708      0  26248   0   0     2     5 1003    12   2   3  95
 2  0  0      0  81692      0  26248   0   0     2     5 1003    12   2   3  95
 2  0  0      0  81696      0  26248   0   0     2     5 1003    12   2   3  95
 2  0  0      0  81708      0  26248   0   0     2     5 1003    12   2   3  95
 2  0  0      0  81692      0  26248   0   0     2     5 1003    12   2   3  95
 2  0  0      0  81696      0  26248   0   0     2     5 1003    12   2   3  95
 2  0  0      0  81708      0  26248   0   0     2     5 1003    12   2   3  95
Interrupt

> Between, we still don't know why doing a sync after an "rm" command
> triggers the garbage collector.  Do you have any other clue about it? 

Not off-hand. 

--
dwmw2

  reply	other threads:[~2002-07-31 15:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-31 14:48 Memory leak problem with JFFS2 Frederic Giasson
2002-07-31 15:17 ` David Woodhouse [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-07-31 18:18 Frederic Giasson
2002-07-31 16:14 Frederic Giasson
2002-07-31 18:04 ` David Woodhouse
2002-07-03 13:38 Frederic Giasson
2002-07-10  9:47 ` David Woodhouse

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=23196.1028128636@redhat.com \
    --to=dwmw2@infradead.org \
    --cc=fgiasson@mediatrix.com \
    --cc=linux-mtd@lists.infradead.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