From: Matthew Wilcox <willy@infradead.org>
To: Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
David Rientjes <rientjes@google.com>,
Zhaoyang Huang <zhaoyang.huang@unisoc.com>,
Roman Gushchin <guro@fb.com>, Jeff Layton <jlayton@redhat.com>,
"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [RFC PATCH] mm/workingset : judge file page activity via timestamp
Date: Wed, 17 Apr 2019 06:37:25 -0700 [thread overview]
Message-ID: <20190417133724.GC7751@bombadil.infradead.org> (raw)
In-Reply-To: <CAGWkznHgc68AHOs2WNPARmwMMKazuKXL1R4VsPD_jwtzQeVK_Q@mail.gmail.com>
On Wed, Apr 17, 2019 at 08:26:22PM +0800, Zhaoyang Huang wrote:
[quoting Johannes here]
> As Matthew says, you are fairly randomly making refault activations
> more aggressive (especially with that timestamp unpacking bug), and
> while that expectedly boosts workload transition / startup, it comes
> at the cost of disrupting stable states because you can flood a very
> active in-ram workingset with completely cold cache pages simply
> because they refault uniformly wrt each other.
> [HZY]: I analysis the log got from trace_printk, what we activate have
> proven record of long refault distance but very short refault time.
You haven't addressed my point, which is that you were only testing
workloads for which your changed algorithm would improve the results.
What you haven't done is shown how other workloads would be negatively
affected.
Once you do that, we can make a decision about whether to improve your
workload by X% and penalise that other workload by Y%.
next prev parent reply other threads:[~2019-04-17 13:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 7:47 [RFC PATCH] mm/workingset : judge file page activity via timestamp Zhaoyang Huang
2019-04-17 7:59 ` Zhaoyang Huang
2019-04-17 10:55 ` Zhaoyang Huang
2019-04-17 11:06 ` Michal Hocko
2019-04-17 11:36 ` Zhaoyang Huang
2019-04-17 11:46 ` Michal Hocko
2019-04-17 12:26 ` Zhaoyang Huang
2019-04-17 12:58 ` Michal Hocko
2019-04-17 13:37 ` Matthew Wilcox [this message]
2019-04-23 11:43 ` Zhaoyang Huang
2019-04-17 8:45 ` Michal Hocko
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=20190417133724.GC7751@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=huangzhaoyang@gmail.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jlayton@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=zhaoyang.huang@unisoc.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).