linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Shaohua Li <shli@fb.com>, linux-mm@kvack.org
Cc: Kernel-team@fb.com, Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH] vmscan: get_scan_count selects anon pages conservative
Date: Wed, 04 Mar 2015 15:52:55 -0500	[thread overview]
Message-ID: <54F770A7.2030205@redhat.com> (raw)
In-Reply-To: <d8192a90f6f9b474b33ec732b88b8b2d7e8623cd.1425499261.git.shli@fb.com>

On 03/04/2015 03:03 PM, Shaohua Li wrote:
> kswapd is a per-node based. Sometimes there is imbalance between nodes,
> node A is full of clean file pages (easy to reclaim), node B is
> full of anon pages (hard to reclaim). With memory pressure, kswapd will
> be waken up for both nodes. The kswapd of node B will try to swap, while
> we prefer reclaim pages from node A first. The real issue here is we
> don't have a mechanism to prevent memory allocation from a hard-reclaim
> node (node B here) if there is an easy-reclaim node (node A) to reclaim
> memory.
> 
> The swap can happen even with swapiness 0. Below is a simple script to
> trigger it. cpu 1 and 8 are in different node, each has 72G memory:
> truncate -s 70G img
> taskset -c 8 dd if=img of=/dev/null bs=4k
> taskset -c 1 usemem 70G
> 
> The swap can even easier to trigger because we have a protect mechanism
> for situation file pages are less than high watermark. This logic makes
> sense but could be more conservative.
> 
> This patch doesn't try to fix the kswapd imbalance issue above, but make
> get_scan_count more conservative to select anon pages. The protect
> mechanism is designed for situation file pages are rotated frequently.
> In that situation, page reclaim should be in trouble, eg, priority is
> lower. So let's only apply the protect mechanism in that situation. In
> pratice, this fixes the swap issue in above test.
> 
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Signed-off-by: Shaohua Li <shli@fb.com>

Doh, never mind my earlier comment. I must be too tired
to look at stuff right...

I see how your patch helps avoid the problem, but I am
worried about potential side effects. I suspect it could
lead to page cache thrashing when all zones are low on
page cache memory.

Would it make sense to explicitly check that we are low
on page cache pages in all zones on the scan list, before
forcing anon only scanning, when we get into this function?


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

  parent reply	other threads:[~2015-03-04 20:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04 20:03 Shaohua Li
2015-03-04 20:17 ` Rik van Riel
2015-03-04 20:52 ` Rik van Riel [this message]
2015-03-06 21:13   ` Shaohua Li

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=54F770A7.2030205@redhat.com \
    --to=riel@redhat.com \
    --cc=Kernel-team@fb.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=shli@fb.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