Re: NTFS - Kernel memory leak in driver for kernel 2.4.28?

[Martin Bogomolni]

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@xxxxxxxxxxxx> 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.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/