A group of us from the handhelds.org site think that we have found a memory
leak in the ramfs file system. After a long period of create and deleting
small files in a mounted ramfs partition we have substantially less freemem.
The problem has been confirmed on 2.4.2 on an i386 and StormARM ports.
The problem was found by a developer running an application on an iPAQ that
quickly writes a 4K file to the ramfs, does some editing of the file and it
then deleted. The application will quickly eat up all free memory and cause
the platform to fail within 5 minutes.
Test case: from a shell, run this short script for a long period of time (over
1 hour):
i=0 ; while : ; do echo 1 >$i ; rm $i ; i=`expr $i + 1` ; done
This test was run on an Compaq iPAQ 3650 using the 2.4.2-rmk1-np3 kernel from
the CVS repository on cvs.handhelds.org.
The following two data points are the output from /proc/meminfo. The first
'cat' was done about 1 minute after the loop has been running. The second
'cat' was done 10 minutes after the script loop had been killed.
# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 31686656 21446656 10240000 0 0 11264000
Swap: 0 0 0
MemTotal: 30944 kB
MemFree: 10000 kB
MemShared: 0 kB
Buffers: 0 kB
Cached: 11000 kB
Active: 4656 kB
Inact_dirty: 4220 kB
Inact_clean: 2124 kB
Inact_target: 0 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 30944 kB
LowFree: 10000 kB
SwapTotal: 0 kB
SwapFree: 0 kB
# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 31686656 24178688 7507968 0 0 12357632
Swap: 0 0 0
MemTotal: 30944 kB
MemFree: 7332 kB
MemShared: 0 kB
Buffers: 0 kB
Cached: 12068 kB
Active: 4560 kB
Inact_dirty: 5384 kB
Inact_clean: 2124 kB
Inact_target: 16 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 30944 kB
LowFree: 7332 kB
SwapTotal: 0 kB
SwapFree: 0 kB
--
Stephen L Johnson <[email protected]>
In article <[email protected]>,
Stephen L Johnson <[email protected]> wrote:
>
>A group of us from the handhelds.org site think that we have found a memory
>leak in the ramfs file system. After a long period of create and deleting
>small files in a mounted ramfs partition we have substantially less freemem.
>The problem has been confirmed on 2.4.2 on an i386 and StormARM ports.
What does /proc/slabinfo say? The most likely leak is a dentry leak or
an inode leak, and both of those should be fairly easy to see in the
slab info (dentry_cache and inode_cache respectively).
Obviously, it could be a data page leak too, but such a leak should be
easy to see by creating a few big files and deleting them..
Linus
Dear Linus,
> What does /proc/slabinfo say? The most likely leak is a dentry leak or
> an inode leak, and both of those should be fairly easy to see in the
> slab info (dentry_cache and inode_cache respectively).
>
I am attaching details before and during my application .
Mainly changes are in dentry_cache and inode_cache , but i am attaching
whole /proc/slabinfo for your reference.
> Obviously, it could be a data page leak too, but such a leak should be
> easy to see by creating a few big files and deleting them..
>
> Linus
I am also facing one more problem with ramfs.
du and df shows 0 , so i am also attaching its output.
Thanks for your help,
Best Regards,
Jaswinder.
--
These are my opinions not 3Di.
>(none):/mnt/ramfs/root# df -h /mnt/ramfs/
>Filesystem Size Used Avail Use% Mounted on
>ramfs 0 0 0 - /mnt/ramfs
I am not sure, how related this is, but we have / on ramfs and using rpm
to install(-iUvh) fails with the mesages, need 12K on /
Amit
On Thu, 29 Mar 2001, Amit D Chaudhary wrote:
> >(none):/mnt/ramfs/root# df -h /mnt/ramfs/
> >Filesystem Size Used Avail Use% Mounted on
> >ramfs 0 0 0 - /mnt/ramfs
> I am not sure, how related this is, but we have / on ramfs and using rpm
> to install(-iUvh) fails with the mesages, need 12K on /
This is normal -- ramfs doesn't do filesystem accounting needed for 'df'.
On Mon, 12 Jun 2000, Jaswinder Singh wrote:
> > What does /proc/slabinfo say? The most likely leak is a dentry leak or
> > an inode leak, and both of those should be fairly easy to see in the
> > slab info (dentry_cache and inode_cache respectively).
> >
>
> I am attaching details before and during my application .
>
> Mainly changes are in dentry_cache and inode_cache , but i am attaching
> whole /proc/slabinfo for your reference.
Would it be possible for you to attached a 'before' picture of slabinfo,
as well as 'after'?
> > Obviously, it could be a data page leak too, but such a leak should be
> > easy to see by creating a few big files and deleting them..
> >
> > Linus
>
> I am also facing one more problem with ramfs.
>
> du and df shows 0 , so i am also attaching its output.
I don't recall how du works exactly... if it uses stat(2), it should not
be broken AFAIK.
As for 'df', that will definitely show zero, because ramfs does not do
filesystem accounting in its present form. You might consider trying a
modified version of ramfs, as found in Alan Cox's 'ac' patchkit. This
patchkit includes a modified ramfs which supports limiting filesystem
size, but more importantly (for you), it should make 'df' work again.
Jeff
Hi,
Thanks for the reply.
So the question next would be whether ramfs will include features to make it
viable or stay with less features with the aim of keeping it simple.
Today, plan to check the 2-4.2-ac2x series to see if they fix this.
Regards
Amit
Jeff Garzik wrote:
> On Thu, 29 Mar 2001, Amit D Chaudhary wrote:
>
>> >(none):/mnt/ramfs/root# df -h /mnt/ramfs/
>> >Filesystem Size Used Avail Use% Mounted on
>> >ramfs 0 0 0 - /mnt/ramfs
>> I am not sure, how related this is, but we have / on ramfs and using rpm
>> to install(-iUvh) fails with the mesages, need 12K on /
>
>
> This is normal -- ramfs doesn't do filesystem accounting needed for 'df'.
Hi,
After testing with patch-2.4.2-ac28, the df commands works fine on a dir
mounted as ramfs. Also, it recognizes the limits set, etc.
Thanks to David Gibson, Alan and others for making this available.
Regards
Amit