From: "U.Mutlu" <for-gmane@mutluit.com>
To: util-linux@vger.kernel.org
Subject: Re: fsck memory leak
Date: Fri, 4 Dec 2015 23:26:30 +0100 [thread overview]
Message-ID: <n3t3um$inb$1@ger.gmane.org> (raw)
In-Reply-To: <201512042240.19891.sweet_f_a@gmx.de>
Ruediger Meier wrote on 12/04/2015 10:40 PM:
> On Friday 04 December 2015, U.Mutlu wrote:
>> I think it's a double-edged sword: if user has less memory then
>> the integrated caching will IMO degrade the performance.
>
> It will use as much memory as available (not more). Ideally Linux would
> use always 100% memory. You've spent money for memory ... why you
> wouldn't want to use it?
>
> After ...
> $ echo 3 > /proc/sys/vm/drop_caches
>
> ... my memory looks like this:
> $ free -h
> total used free shared buffers cached
> Mem: 7.7G 1.8G 6.0G 230M 4.4M 487M
> -/+ buffers/cache: 1.3G 6.5G
> Swap: 1.7G 68M 1.6G
>
> Then after ...
> $ dd if=/dev/sda of=/dev/null count=8K bs=1M
>
> ... cache/buffer is filled
> $ free -h
> total used free shared buffers cached
> Mem: 7.7G 7.6G 168M <=(1) 230M 5.6G 665M
> -/+ buffers/cache: 1.3G 6.5G <=(2)
> Swap: 1.7G 68M 1.6G
>
> ... and this should not change until reboot.
>
> (1) shows that almost 100% memory is "in use"
> (2) shows that it's just buffer or cache
Try the test with fsck at boot with drop_caches=0, and you will get an
illogical result as shown in my initial posting.
I'm not a friend of such default integrated system caching, it reminds
me of Windows idiocy. This is nothing but a diskcache in ram, but then
the admin should have the the freedom to set the size of the cache via
a config file in etc, for example /etc/default/cache or in /etc/default/tmpfs.
> sorun yapma ;)
:-)
> Rudi
next prev parent reply other threads:[~2015-12-04 22:26 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
2015-12-04 20:31 ` U.Mutlu
2015-12-04 21:40 ` Ruediger Meier
2015-12-04 22:26 ` U.Mutlu [this message]
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='n3t3um$inb$1@ger.gmane.org' \
--to=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 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.