From: Aaron Lu <aaron.lwe@gmail.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
js1304@gmail.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Michal Hocko <mhocko@kernel.org>,
Hugh Dickins <hughd@google.com>, Minchan Kim <minchan@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>,
Mel Gorman <mgorman@techsingularity.net>,
kernel-team@lge.com, Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH v2 0/9] workingset protection/detection on the anonymous LRU list
Date: Fri, 28 Feb 2020 11:23:58 +0800 [thread overview]
Message-ID: <20200228032358.GB634650@ziqianlu-desktop.localdomain> (raw)
In-Reply-To: <20200227134806.GC39625@cmpxchg.org>
On Thu, Feb 27, 2020 at 08:48:06AM -0500, Johannes Weiner wrote:
> On Wed, Feb 26, 2020 at 07:39:42PM -0800, Andrew Morton wrote:
> > It sounds like the above simple aging changes provide most of the
> > improvement, and that the workingset changes are less beneficial and a
> > bit more risky/speculative?
> >
> > If so, would it be best for us to concentrate on the aging changes
> > first, let that settle in and spread out and then turn attention to the
> > workingset changes?
>
> Those two patches work well for some workloads (like the benchmark),
> but not for others. The full patchset makes sure both types work well.
>
> Specifically, the existing aging strategy for anon assumes that most
> anon pages allocated are hot. That's why they all start active and we
> then do second-chance with the small inactive LRU to filter out the
> few cold ones to swap out. This is true for many common workloads.
>
> The benchmark creates a larger-than-memory set of anon pages with a
> flat access profile - to the VM a flood of one-off pages. Joonsoo's
test: swap-w-rand-mt, which is a multi thread swap write intensive
workload so there will be swap out and swap ins.
> first two patches allow the VM to usher those pages in and out of
Weird part is, the robot says the performance gain comes from the 1st
patch only, which adjust the ratio, not including the 2nd patch which
makes anon page starting from inactive list.
I find the performance gain hard to explain...
> memory very quickly, which explains the throughput boost. But it comes
> at the cost of reducing space available to hot anon pages, which will
> regress others.
>
next prev parent reply other threads:[~2020-02-28 3:24 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 5:11 js1304
2020-02-20 5:11 ` [PATCH v2 1/9] mm/vmscan: make active/inactive ratio as 1:1 for anon lru js1304
2020-03-12 14:47 ` Johannes Weiner
2020-03-13 5:48 ` Joonsoo Kim
2020-02-20 5:11 ` [PATCH v2 2/9] mm/vmscan: protect the workingset on anonymous LRU js1304
2020-03-12 15:14 ` Johannes Weiner
2020-03-13 7:40 ` Joonsoo Kim
2020-03-13 19:55 ` Johannes Weiner
2020-03-16 7:05 ` Joonsoo Kim
2020-03-16 16:12 ` Johannes Weiner
2020-03-17 4:52 ` Joonsoo Kim
2020-02-20 5:11 ` [PATCH v2 3/9] mm/workingset: extend the workingset detection for anon LRU js1304
2020-02-20 5:11 ` [PATCH v2 4/9] mm/swapcache: support to handle the value in swapcache js1304
2020-02-20 5:11 ` [PATCH v2 5/9] mm/workingset: use the node counter if memcg is the root memcg js1304
2020-02-20 5:11 ` [PATCH v2 6/9] mm/workingset: handle the page without memcg js1304
2020-02-20 5:11 ` [PATCH v2 7/9] mm/swap: implement workingset detection for anonymous LRU js1304
2020-02-20 5:11 ` [PATCH v2 8/9] mm/vmscan: restore active/inactive ratio " js1304
2020-02-20 5:11 ` [PATCH v2 9/9] mm/swap: count a new anonymous page as a reclaim_state's rotate js1304
2020-02-27 3:39 ` [PATCH v2 0/9] workingset protection/detection on the anonymous LRU list Andrew Morton
2020-02-27 7:48 ` Joonsoo Kim
2020-03-01 4:40 ` Andrew Morton
2020-02-27 13:48 ` Johannes Weiner
2020-02-27 23:36 ` Andrew Morton
2020-03-02 23:31 ` Joonsoo Kim
2020-03-11 7:27 ` Joonsoo Kim
2020-02-28 3:23 ` Aaron Lu [this message]
2020-02-28 4:03 ` Joonsoo Kim
2020-02-28 5:57 ` Aaron Lu
2020-02-28 6:52 ` Joonsoo Kim
2020-02-28 9:17 ` Aaron Lu
2020-02-28 9:56 ` Joonsoo Kim
2020-02-28 10:21 ` Aaron Lu
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=20200228032358.GB634650@ziqianlu-desktop.localdomain \
--to=aaron.lwe@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=js1304@gmail.com \
--cc=kernel-team@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
--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