All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mm: vmscan: do not swap anon pages just because free+file is low
Date: Fri, 14 Mar 2014 12:06:25 -0400	[thread overview]
Message-ID: <53232901.5030307@redhat.com> (raw)
In-Reply-To: <1394811302-30468-1-git-send-email-hannes@cmpxchg.org>

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 ...

> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> Cc: <stable@kernel.org> [3.12+]

Reviewed-by: Rik van Riel <riel@redhat.com>

-- 
All rights reversed

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Rik van Riel <riel@redhat.com>
To: Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mm: vmscan: do not swap anon pages just because free+file is low
Date: Fri, 14 Mar 2014 12:06:25 -0400	[thread overview]
Message-ID: <53232901.5030307@redhat.com> (raw)
In-Reply-To: <1394811302-30468-1-git-send-email-hannes@cmpxchg.org>

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 ...

> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> Cc: <stable@kernel.org> [3.12+]

Reviewed-by: Rik van Riel <riel@redhat.com>

-- 
All rights reversed

  reply	other threads:[~2014-03-14 16:06 UTC|newest]

Thread overview: 14+ 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 15:35 ` Johannes Weiner
2014-03-14 16:06 ` Rik van Riel [this message]
2014-03-14 16:06   ` Rik van Riel
2014-03-14 17:08   ` Mel Gorman
2014-03-14 17:08     ` Mel Gorman
2014-03-16  4:20     ` Hugh Dickins
2014-03-16  4:20       ` Hugh Dickins
2014-03-17 15:15       ` Johannes Weiner
2014-03-17 15:15         ` Johannes Weiner
2014-03-17 18:33         ` Hugh Dickins
2014-03-17 18:33           ` Hugh Dickins
2014-03-14 17:06 ` Rafael Aquini
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=53232901.5030307@redhat.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    /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.