From: Mel Gorman <mgorman@suse.de>
To: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org, mhocko@suse.cz
Subject: Re: [patch] mm: vmscan: do not swap anon pages just because free+file is low
Date: Fri, 14 Mar 2014 17:08:08 +0000 [thread overview]
Message-ID: <20140314170807.GW10663@suse.de> (raw)
In-Reply-To: <53232901.5030307@redhat.com>
On Fri, Mar 14, 2014 at 12:06:25PM -0400, Rik van Riel wrote:
> On 03/14/2014 11:35 AM, Johannes Weiner wrote:
> > Page reclaim force-scans / swaps anonymous pages when file cache drops
> > below the high watermark of a zone in order to prevent what little
> > cache remains from thrashing.
> >
> > However, on bigger machines the high watermark value can be quite
> > large and when the workload is dominated by a static anonymous/shmem
> > set, the file set might just be a small window of used-once cache. In
> > such situations, the VM starts swapping heavily when instead it should
> > be recycling the no longer used cache.
> >
> > This is a longer-standing problem, but it's more likely to trigger
> > after 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
> > because file pages can no longer accumulate in a single zone and are
> > dispersed into smaller fractions among the available zones.
> >
> > To resolve this, do not force scan anon when file pages are low but
> > instead rely on the scan/rotation ratios to make the right prediction.
>
> I am not entirely sure that the scan/rotation ratio will be
> meaningful when the page cache has been essentially depleted,
> but on larger systems the distance between the low and high
> watermark is gigantic, and I have no better idea on how to
> fix the bug you encountered, so ...
>
I still agree with the direction in general even though I've not put
thought into this specific patch yet. We've observed a problem whereby force
reclaim was causing one or other LRU list to be trashed. In one specific
case, the inactive file is low logic was causing problems because while
the relative size of inactive/active was taken into account, the absolute
size vs anon was not. It was not a mainline kernel and we do not have a
test configuration that properly illustrates the problem on mainline it's
on our radar that it's a potential problem. The scan/rotation ratio at the
moment does not take absolute sizes into account but we almost certainly
want to go in that direction at some stage. Hugh's patch on altering how
proportional shrinking works is also relevant.
--
Mel Gorman
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-03-14 17:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-14 15:35 [patch] mm: vmscan: do not swap anon pages just because free+file is low Johannes Weiner
2014-03-14 16:06 ` Rik van Riel
2014-03-14 17:08 ` Mel Gorman [this message]
2014-03-16 4:20 ` Hugh Dickins
2014-03-17 15:15 ` Johannes Weiner
2014-03-17 18:33 ` Hugh Dickins
2014-03-14 17:06 ` Rafael Aquini
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=20140314170807.GW10663@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--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).