From: "Theodore Ts'o" <tytso@mit.edu>
To: "U.Mutlu" <for-gmane@mutluit.com>
Cc: util-linux@vger.kernel.org
Subject: Re: fsck memory leak
Date: Fri, 4 Dec 2015 14:58:48 -0500 [thread overview]
Message-ID: <20151204195848.GA18359@thunk.org> (raw)
In-Reply-To: <n3sjvh$ib8$1@ger.gmane.org>
On Fri, Dec 04, 2015 at 06:53:53PM +0100, U.Mutlu wrote:
> >Please send the output of cat /proc/meminfo (a) before running fsck,
> >(b) after running fsck, and then (c) after running "echo 3 >
> >/proc/sys/vm/drop_caches".
>
> Just tried it out.
> Doing "echo 3 > /proc/sys/vm/drop_caches" solves the problem.
There's no problem then --- except in your understanding of how
Linux's memory management system works.
Linux keeps data that was read from disk in its buffer and page cache,
because there is always a chance that data could be needed again. So
although it looks like free space is being consumed by the buffer and
page caches, if those pages are clean (not dirty; if they were
modified, we've gotten around to writing the modified data back to
disk) and inactive (not installed in some process's page table, such
that the page is visible in some process's virtual address space),
even though those pages aren't counted as "free" memory, it can be
instantly reused for something else.
So doing something like "echo 3 > /proc/sys/vm/drop_caches" is
actually a _bad_ thing, since it means you are throwing away data that
could be used to avoid blocking waiting for disk I/O to complete.
However, if it helps satisfy some system administrator's insecurity
because they are looking at this field:
total used free shared buff/cache available
Mem: 15G 4.4G ==> 4.5G <== 392M 6.4G 10G
Swap: 0B 0B 0B
when they should be looking at *this* field:
total used free shared buff/cache available
Mem: 15G 4.4G 4.5G 392M 6.4G ===> 10G <===
Swap: 0B 0B 0B
It's just being silly.
Yes, after doing the "echo 3 > /proc/sys/vm/drop_caches", you would
see this instead:
total used free shared buff/cache available
Mem: 15G 4.1G 10G 390M 927M 10G
Swap: 0B 0B 0B
But reducing the size of buff/cache is not a win! If you suddenly
need the memory because you suddently started some memory hog such as
Eclipse, the system will automatically reclaim the clean and inactive
pages for use by the new memory user. But until then, why not keep
the cache pages around just in case they are needed?
Regards,
- Ted
next prev parent reply other threads:[~2015-12-04 19:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-04 7:15 fsck memory leak U.Mutlu
2015-12-04 7:49 ` U.Mutlu
2015-12-04 10:21 ` Karel Zak
2015-12-04 18:00 ` U.Mutlu
2015-12-04 15:19 ` Theodore Ts'o
2015-12-04 17:53 ` U.Mutlu
2015-12-04 19:09 ` U.Mutlu
2015-12-04 19:58 ` Theodore Ts'o [this message]
2015-12-04 20:31 ` U.Mutlu
2015-12-04 21:40 ` Ruediger Meier
2015-12-04 22:26 ` U.Mutlu
2015-12-04 22:03 ` Mike Frysinger
2015-12-04 22:17 ` Theodore Ts'o
2015-12-04 22:01 ` Mike Frysinger
-- strict thread matches above, loose matches on Subject: below --
2015-12-04 23:08 Dave Rutherford
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=20151204195848.GA18359@thunk.org \
--to=tytso@mit.edu \
--cc=for-gmane@mutluit.com \
--cc=util-linux@vger.kernel.org \
/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