From: Andrew Morton <akpm@linux-foundation.org>
To: "Alexander Stohr" <Alexander.Stohr@gmx.de>
Cc: linux-kernel@vger.kernel.org, trond.myklebust@fys.uio.no,
riel@redhat.com, major@mhtx.net
Subject: Re: [BUG?] vfs_cache_pressure=0 does not free inode caches
Date: Mon, 10 May 2010 14:18:44 -0700 [thread overview]
Message-ID: <20100510141844.3a3c74df.akpm@linux-foundation.org> (raw)
In-Reply-To: <20100510172621.284310@gmx.net>
On Mon, 10 May 2010 19:26:21 +0200
"Alexander Stohr" <Alexander.Stohr@gmx.de> wrote:
> this is a follow up to:
> http://lkml.indiana.edu/hypermail/linux/kernel/0904.1/03026.html
>
> > The server is going to die a slow death,
> > all user space memory is swapped out,
> > then all processes are OOM killed
> > until it dies from complete memory exhaustion."
>
> > a cache is supposed to be a cache and not a memory hog
>
> i'm running an embedded system with NFS as my working area.
> the system has only few ram leftover, any MiBi counts.
>
> my current best guess to resolve low memory situations
> is a manual one (no, i could not see any smart kernel reaction
> with that relatively old but patched 2.6.18 kernel) is this:
>
> echo 100000 >/proc/sys/vm/vfs_cache_pressure
> sync
> echo 1 >/proc/sys/vm/drop_caches
> echo 2 >/proc/sys/vm/drop_caches
>
> any hints on that?
> is this still an issue in current kernels
> or is this already addressed in some way?
>
I'm not sure what to say, really.
If you tell the kernel not to reclaim inode/dentry caches then it will
do what you asked. It _sounds_ like you're looking for more aggressive
reclaim of the VFS caches when the system is getting low on memory.
Perhaps this can be done by _increasing_ vfs_cache_pressure. But the
kernel should wring the last drop out of the VFS caches before
declaring OOM anyway - if it isn't doing that, we should fix it.
Perhaps you could tell us exactly what behaviour you're observing, and
how it differs from what you'd like to see.
>
>
> here is the link to the initial patch set applied to 2.6.8:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commit;h=95afb3658a8217ff2c262e202601340323ef2803
>
> some other people spotting similar effects:
> http://rackerhacker.com/2008/12/03/reducing-inode-and-dentry-caches-to-keep-oom-killer-at-bay/
That page says "If you are writing data at the time you run these
commands, you'll actually be dumping the data out of the filesystem
cache before it reaches the disk, which could lead to very bad things".
That had better not be true! That would be a bad bug. drop_caches
only drops stuff which has been written back.
next prev parent reply other threads:[~2010-05-10 21:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 17:26 [BUG?] vfs_cache_pressure=0 does not free inode caches Alexander Stohr
2010-05-10 21:18 ` Andrew Morton [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-05-11 8:47 Alexander Stohr
2009-04-14 15:54 Christian Thaeter
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=20100510141844.3a3c74df.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Alexander.Stohr@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=major@mhtx.net \
--cc=riel@redhat.com \
--cc=trond.myklebust@fys.uio.no \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox