From: Michal Hocko <mhocko@suse.cz>
To: Xishi Qiu <qiuxishi@huawei.com>
Cc: Rafael Aquini <aquini@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Wanpeng Li <liwanp@linux.vnet.ibm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Li Zefan <lizefan@huawei.com>
Subject: Re: [PATCH 0/8] mm: add page cache limit and reclaim feature
Date: Fri, 20 Jun 2014 17:32:12 +0200 [thread overview]
Message-ID: <20140620153212.GD23115@dhcp22.suse.cz> (raw)
In-Reply-To: <53A3E948.5020701@huawei.com>
On Fri 20-06-14 15:56:56, Xishi Qiu wrote:
> On 2014/6/17 9:35, Xishi Qiu wrote:
>
> > On 2014/6/16 20:50, Rafael Aquini wrote:
> >
> >> On Mon, Jun 16, 2014 at 01:14:22PM +0200, Michal Hocko wrote:
> >>> On Mon 16-06-14 17:24:38, Xishi Qiu wrote:
> >>>> When system(e.g. smart phone) running for a long time, the cache often takes
> >>>> a large memory, maybe the free memory is less than 50M, then OOM will happen
> >>>> if APP allocate a large order pages suddenly and memory reclaim too slowly.
> >>>
> >>> Have you ever seen this to happen? Page cache should be easy to reclaim and
> >>> if there is too mach dirty memory then you should be able to tune the
> >>> amount by dirty_bytes/ratio knob. If the page allocator falls back to
> >>> OOM and there is a lot of page cache then I would call it a bug. I do
> >>> not think that limiting the amount of the page cache globally makes
> >>> sense. There are Unix systems which offer this feature but I think it is
> >>> a bad interface which only papers over the reclaim inefficiency or lack
> >>> of other isolations between loads.
> >>>
> >> +1
> >>
> >> It would be good if you could show some numbers that serve as evidence
> >> of your theory on "excessive" pagecache acting as a trigger to your
> >> observed OOMs. I'm assuming, by your 'e.g', you're running a swapless
> >> system, so I would think your system OOMs are due to inability to
> >> reclaim anon memory, instead of pagecache.
> >>
>
> I asked some colleagues, when the cache takes a large memory, it will not
> trigger OOM, but performance regression.
>
> It is because that business process do IO high frequency, and this will
> increase page cache. When there is not enough memory, page cache will
> be reclaimed first, then alloc a new page, and add it to page cache. This
> often takes too much time, and causes performance regression.
I cannot say I would understand the problem you are describing. So the
page cache eats the most of the memory and that increases allocation
latency for new page cache? Is it because of the direct reclaim?
Why kswapd doesn't reclaim the clean pagecache? Or is the memory dirty?
> In view of this situation, if we reclaim page cache in circles may be
> fix this problem. What do you think?
No, it seems more like either system misconfiguration or a reclaim bug.
--
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:[~2014-06-20 15:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 9:24 [PATCH 0/8] mm: add page cache limit and reclaim feature Xishi Qiu
2014-06-16 10:04 ` Zhang Yanfei
2014-06-16 10:42 ` Xishi Qiu
2014-06-16 11:14 ` Michal Hocko
2014-06-16 12:50 ` Rafael Aquini
2014-06-17 1:35 ` Xishi Qiu
2014-06-20 7:56 ` Xishi Qiu
2014-06-20 15:32 ` Michal Hocko [this message]
2014-06-23 2:05 ` Xishi Qiu
2014-06-23 11:29 ` Michal Hocko
2014-06-24 2:25 ` Xishi Qiu
2014-06-24 7:36 ` Michal Hocko
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=20140620153212.GD23115@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=aquini@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liwanp@linux.vnet.ibm.com \
--cc=lizefan@huawei.com \
--cc=peterz@infradead.org \
--cc=qiuxishi@huawei.com \
--cc=riel@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).