From: Michal Hocko <mhocko@suse.cz>
To: Cheng Rk <crquan@ymail.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: How to controll Buffers to be dilligently reclaimed?
Date: Wed, 18 Feb 2015 15:23:22 +0100 [thread overview]
Message-ID: <20150218142322.GD4680@dhcp22.suse.cz> (raw)
In-Reply-To: <131740628.109294.1423821136530.JavaMail.yahoo@mail.yahoo.com>
On Fri 13-02-15 09:52:16, Cheng Rk wrote:
>
>
> On Thursday, February 12, 2015 11:34 PM, Konstantin Khlebnikov <koct9i@gmail.com> wrote:
>
> >>
> >> -bash-4.2$ sudo losetup -a
> >> /dev/loop0: [0005]:16512 (/dev/dm-2)
> >> -bash-4.2$ free -m
> >> total used free shared buffers cached
> >> Mem: 48094 46081 2012 40 40324 2085
> >> -/+ buffers/cache: 3671 44422
> >> Swap: 8191 5 8186
> >>
> >>
> >> I've tried sysctl mm.vfs_cache_pressure=10000 but that seems working to Cached
> >> memory, I wonder is there another sysctl for reclaming Buffers?
>
> > AFAIK "Buffers" is just a page-cache of block devices.
> > From reclaimer's point of view they have no difference from file page-cache.
>
> > Could you post oom-killer log, there should be a lot of numbers
> > describing memory state.
>
>
> in this case, 40GB memory got stuck in Buffers, and 90+% of them are
> reclaimable (can be verified by vm.drop_caches manual reclaim) if
> Buffers are treated same as Cached, why mm.vfs_cache_pressure=10000
> (or even I tried up to 1,000,000) can't get Buffers reclaimed early?
As per Documentation/sysctl/vm.txt the knob doesn't affect the page
cache reclaim but rather inode vs. dentry reclaim.
> I have some oom-killer msgs but were with older kernels, after set
> vm.overcommit_memory=2, it simply returns -ENOMEM, unable to spawn any
> new container, why doesn't it even try to reclaim some memory from
> those 40GB Buffers,
overcommit_memory controls behavior of the _virtual_ memory
reservations. OVERCOMMIT_NEVER (2) means that even virtual memory cannot
be overcommit outside of the configured value (RAM + swap basically -
see Documentation/vm/overcommit-accounting for more information). So
your application most probably consumes a lot of virtual memory (mmaps
etc.) and that is why it gets ENOMEM.
OOM report would tell us what was the memory state at the time when you
were short of memory and why the cache (buffers in your case) were not
reclaimed properly.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-02-18 14:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-13 0:52 Cheng Rk
2015-02-13 7:34 ` Konstantin Khlebnikov
2015-02-13 9:52 ` Cheng Rk
2015-02-13 18:07 ` Cheng Rk
2015-02-18 14:23 ` Michal Hocko [this message]
2015-02-18 19:44 ` Cheng Rk
2015-02-19 9:46 ` Michal Hocko
2015-02-20 20:33 ` Cheng Rk
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=20150218142322.GD4680@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=crquan@ymail.com \
--cc=koct9i@gmail.com \
--cc=linux-mm@kvack.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