kernel 2.4 inode/dentry cache not clearing on umount?

[Martin Bogomolni <martinbogo@gmail.com>]

Also .. David :

Are you saying that, on a system with 256Megs of ram, of which the
kernel is reporting only 3-4Mb free because the inode/dentry caches
are taking up most of the memory, and NO page/swap file....

char *p;
p = (char *) malloc( 64*1024*1024 );

I assure you that under these conditions, the malloc( ) will fail with NULL.

---------------------------------

Now, in the meantime I have discovered that merely unmounting the
filesystem is not enough to clear the dcache and icache.

However, if I unmount the filesystem then run:

cat /dev/hda > /dev/null 

This causes the inode/dentry cache to finally shrink and the amount of
available free memory increases back to ~200Mb.   However, this
reduction does not immediately take place when the filesystem is
unmounted, and while the filesystem is mounted .. the inode/dentry
cache does not shrink and leaves only 3Mb of available free memory.




On Wed, 16 Feb 2005 09:16:40 -0800, Martin Bogomolni
<martinbogo@gmail.com> wrote:
> Dick,
> 
> I should say that the malloc() succeeds, but the 16mb I need for the
> buffer are not available.  Since there is no swap/page file in the
> embedded environment, there isn't enough memory left afterwards for
> the buffer.
> 
> After taking another look at the problem, the kernel has a lot of
> memory tied up in the inode and dentry cache.   I've tuned
> /proc/sys/vm/vm_cache_scan_ratio, vm_mapped_ratio, vm_vfs_scan_ratio
> with no real success in shrinking the amount of memory used by these
> caches.
> 
> Is there a way to tune and shring the overall amount of memory the
> kernel attempts to use for the dentry/inode cache, or make it much,
> much more aggressive at clearing it?
> 
> -Martin
> 
> 
> On Wed, 16 Feb 2005 12:00:53 -0500 (EST), linux-os
> <linux-os@analogic.com> wrote:
> > On Wed, 16 Feb 2005, Martin Bogomolni wrote:
> >
> > [SNIPPED...]
> >
> > > after the 'find' command is run.   malloc( ) fails to allocate
> > > afterwards. so the kernel does not free any of the missing RAM for
> > > malloc( ).
> > >
> >
> > Whatever program is using malloc() is either corrupting
> > its buffers or has a memory leak.
> >
> > Malloc() will always succeed even if the kernel has no
> > memory available. This is because the actual allocation
> > only occurs when the program attempts to write to one
> > of those pages malloc() "promised".
> >
> > When you look at kernel memory after using `find` everything,
> > the directory of everything you have accessed remains in
> > memory until the kernel needs page(s) to give to processes.
> >
> > So, the bottom line is, if malloc() returns NULL, you have
> > a problem with your program. It has nothing to do with
> > the kernel and "discovering" that the kernel has used
> > all available RAM for temporary buffers is not interesting.
> >
> > [SNIPPED...]
> >
> > Cheers,
> > Dick Johnson
> > Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
> >  Notice : All mail here is now cached for review by Dictator Bush.
> >                  98.36% of all statistics are fiction.
> >
>