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

From: Martin Bogomolni (martinbogo_at_gmail.com)
Date: 02/16/05

  • Next message: Jeff Sipek: "Re: [BK] upgrade will be needed" 
    Date:	Wed, 16 Feb 2005 09:16:40 -0800
To: linux-os@analogic.com

    ***,

    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,
    > *** 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Jeff Sipek: "Re: [BK] upgrade will be needed"
    • Quantcast