Memory leak problem with JFFS2
Frederic Giasson
fgiasson at mediatrix.com
Wed Jul 31 12:14:58 EDT 2002
You have the right procedure to reproduce the problem ( vmstat ; while true
; do mount -t jffs2 mtd0 /mnt/spare ; ). I can reproduce the problem using
this line on my system.
I updated my JFFS2 code with the lastest from CVS, and I am using kernel
2.4.19-rc2, and the problem is still there. Do you think you could do the
same test under 2.4.19-rc2?
Thanks,
Frédéric Giasson
|-----Original Message-----
|From: David Woodhouse [mailto:dwmw2 at infradead.org]
|Sent: Wednesday, July 31, 2002 11:17 AM
|To: Frederic Giasson
|Cc: linux-mtd at lists.infradead.org
|Subject: Re: Memory leak problem with JFFS2
|
|
|
|fgiasson at 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
|
|
|
More information about the linux-mtd
mailing list