All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Bogomolni <martinbogo@gmail.com>
To: linux-os@analogic.com
Subject: Re: NTFS - Kernel memory leak in driver for kernel 2.4.28?
Date: Wed, 16 Feb 2005 09:16:40 -0800	[thread overview]
Message-ID: <712fce105021609163a605f51@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0502161151370.10018@chaos.analogic.com>

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.
>

  reply	other threads:[~2005-02-16 17:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-16 16:28 NTFS - Kernel memory leak in driver for kernel 2.4.28? Martin Bogomolni
2005-02-16 16:55 ` NTFS - Kernel memory leak in driver for kernel 2.4.28 (update) Martin Bogomolni
2005-02-16 17:00 ` NTFS - Kernel memory leak in driver for kernel 2.4.28? linux-os
2005-02-16 17:16   ` Martin Bogomolni [this message]
2005-02-16 18:03     ` kernel 2.4 inode/dentry cache not clearing on umount? Martin Bogomolni
2005-02-16 18:10       ` Martin Bogomolni
2005-02-17 11:40     ` NTFS - Kernel memory leak in driver for kernel 2.4.28? Anton Altaparmakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=712fce105021609163a605f51@mail.gmail.com \
    --to=martinbogo@gmail.com \
    --cc=linux-os@analogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.