From: Andrey Ryabinin <aryabinin@virtuozzo.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Michal Hocko <mhocko@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>, Rik van Riel <riel@surriel.com>,
Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [PATCH 5/5] mm/vmscan: don't forcely shrink active anon lru list
Date: Tue, 26 Feb 2019 15:04:40 +0300 [thread overview]
Message-ID: <ea0f769b-29e6-8787-7b18-cb7b24c1cda3@virtuozzo.com> (raw)
In-Reply-To: <20190222182249.GC15440@cmpxchg.org>
On 2/22/19 9:22 PM, Johannes Weiner wrote:
> On Fri, Feb 22, 2019 at 08:43:37PM +0300, Andrey Ryabinin wrote:
>> shrink_node_memcg() always forcely shrink active anon list.
>> This doesn't seem like correct behavior. If system/memcg has no swap, it's
>> absolutely pointless to rebalance anon lru lists.
>> And in case we did scan the active anon list above, it's unclear why would
>> we need this additional force scan. If there are cases when we want more
>> aggressive scan of the anon lru we should just change the scan target
>> in get_scan_count() (and better explain such cases in the comments).
>>
>> Remove this force shrink and let get_scan_count() to decide how
>> much of active anon we want to shrink.
>
> This change breaks the anon pre-aging.
>
> The idea behind this is that the VM maintains a small batch of anon
> reclaim candidates with recent access information. On every reclaim,
> even when we just trim cache, which is the most common reclaim mode,
> but also when we just swapped out some pages and shrunk the inactive
> anon list, at the end of it we make sure that the list of potential
> anon candidates is refilled for the next reclaim cycle.
>
> The comments for this are above inactive_list_is_low() and the
> age_active_anon() call from kswapd.
>
> Re: no swap, you are correct. We should gate that rebalancing on
> total_swap_pages, just like age_active_anon() does.
>
I think we should leave anon aging only for !SCAN_FILE cases.
At least aging was definitely invented for the SCAN_FRACT mode which was the
main mode at the time it was added by the commit:
556adecba110bf5f1db6c6b56416cfab5bcab698
Author: Rik van Riel <riel@redhat.com>
Date: Sat Oct 18 20:26:34 2008 -0700
vmscan: second chance replacement for anonymous pages
Later we've got more of the SCAN_FILE mode usage, commit:
e9868505987a03a26a3979f27b82911ccc003752
Author: Rik van Riel <riel@redhat.com>
Date: Tue Dec 11 16:01:10 2012 -0800
mm,vmscan: only evict file pages when we have plenty
and I think would be reasonable to avoid the anon aging in the SCAN_FILE case.
Because if workload generates enough inactive file pages we never go to the SCAN_FRACT,
so aging is just as useless as with no swap case.
So, how about something like bellow on top of the patch?
---
mm/vmscan.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index efd10d6b9510..6c63adfee37b 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2525,6 +2525,15 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
nr[lru] = scan;
}
+
+ /*
+ * Even if we did not try to evict anon pages at all, we want to
+ * rebalance the anon lru active/inactive ratio to maintain
+ * enough reclaim candidates for the next reclaim cycle.
+ */
+ if (scan_balance != SCAN_FILE && inactive_list_is_low(lruvec,
+ false, memcg, sc, false))
+ nr[LRU_ACTIVE_ANON] += SWAP_CLUSTER_MAX;
}
/*
--
2.19.2
next prev parent reply other threads:[~2019-02-26 12:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-22 17:43 [PATCH 1/5] mm/workingset: remove unused @mapping argument in workingset_eviction() Andrey Ryabinin
2019-02-22 17:43 ` [PATCH 2/5] mm: remove zone_lru_lock() function access ->lru_lock directly Andrey Ryabinin
2019-02-25 12:10 ` Vlastimil Babka
2019-02-22 17:43 ` [PATCH 3/5] mm/compaction: pass pgdat to too_many_isolated() instead of zone Andrey Ryabinin
2019-02-22 19:01 ` Rik van Riel
2019-02-25 12:13 ` Vlastimil Babka
2019-02-22 17:43 ` [PATCH 4/5] mm/vmscan: remove unused lru_pages argument Andrey Ryabinin
2019-02-22 18:02 ` Johannes Weiner
2019-02-25 12:17 ` Vlastimil Babka
2019-02-22 17:43 ` [PATCH 5/5] mm/vmscan: don't forcely shrink active anon lru list Andrey Ryabinin
2019-02-22 18:22 ` Johannes Weiner
2019-02-26 12:04 ` Andrey Ryabinin [this message]
2019-02-26 14:42 ` Rik van Riel
2019-02-22 17:58 ` [PATCH 1/5] mm/workingset: remove unused @mapping argument in workingset_eviction() Johannes Weiner
2019-02-22 19:02 ` Rik van Riel
2019-02-25 12:01 ` Vlastimil Babka
2019-02-26 12:07 ` Andrey Ryabinin
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=ea0f769b-29e6-8787-7b18-cb7b24c1cda3@virtuozzo.com \
--to=aryabinin@virtuozzo.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=riel@surriel.com \
--cc=vbabka@suse.cz \
/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
all inboxes | Powered by JetHome®