From: Zi Yan <ziy@nvidia.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Yang Shi <yang.shi@linux.alibaba.com>,
<mgorman@techsingularity.net>, <riel@surriel.com>,
<hannes@cmpxchg.org>, <akpm@linux-foundation.org>,
<keith.busch@intel.com>, <dan.j.williams@intel.com>,
<fengguang.wu@intel.com>, <fan.du@intel.com>,
<ying.huang@intel.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [v2 RFC PATCH 0/9] Another Approach to Use PMEM as NUMA Node
Date: Tue, 16 Apr 2019 12:12:33 -0400 [thread overview]
Message-ID: <027AE219-8C81-47DC-A241-4209C3F656A0@nvidia.com> (raw)
In-Reply-To: <63514bdd-313b-d42f-e582-f8cb350d0b35@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
On 16 Apr 2019, at 11:55, Dave Hansen wrote:
> On 4/16/19 8:33 AM, Zi Yan wrote:
>>> We have a reasonable argument that demotion is better than
>>> swapping. So, we could say that even if a VMA has a strict NUMA
>>> policy, demoting pages mapped there pages still beats swapping
>>> them or tossing the page cache. It's doing them a favor to
>>> demote them.
>> I just wonder whether page migration is always better than
>> swapping, since SSD write throughput keeps improving but page
>> migration throughput is still low. For example, my machine has a
>> SSD with 2GB/s writing throughput but the throughput of 4KB page
>> migration is less than 1GB/s, why do we want to use page migration
>> for demotion instead of swapping?
>
> Just because we observe that page migration apparently has lower
> throughput today doesn't mean that we should consider it a dead end.
I definitely agree. I also want to make the point that we might
want to improve page migration as well to show that demotion via
page migration will work. Since most of proposed demotion approaches
use the same page replacement policy as swapping, if we do not have
high-throughput page migration, we might draw false conclusions that
demotion is no better than swapping but demotion can actually do
much better. :)
--
Best Regards,
Yan Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
next prev parent reply other threads:[~2019-04-16 16:12 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-11 3:56 [v2 RFC PATCH 0/9] Another Approach to Use PMEM as NUMA Node Yang Shi
2019-04-11 3:56 ` [v2 PATCH 1/9] mm: define N_CPU_MEM node states Yang Shi
2019-04-11 3:56 ` [v2 PATCH 2/9] mm: page_alloc: make find_next_best_node find return cpuless node Yang Shi
2019-04-11 3:56 ` [v2 PATCH 3/9] mm: numa: promote pages to DRAM when it gets accessed twice Yang Shi
2019-04-11 3:56 ` [v2 PATCH 4/9] mm: migrate: make migrate_pages() return nr_succeeded Yang Shi
2019-04-11 3:56 ` [v2 PATCH 5/9] mm: vmscan: demote anon DRAM pages to PMEM node Yang Shi
2019-04-11 14:31 ` Dave Hansen
2019-04-15 22:10 ` Yang Shi
2019-04-15 22:14 ` Dave Hansen
2019-04-15 22:26 ` Yang Shi
2019-04-11 3:56 ` [v2 PATCH 6/9] mm: vmscan: don't demote for memcg reclaim Yang Shi
2019-04-11 3:56 ` [v2 PATCH 7/9] mm: vmscan: check if the demote target node is contended or not Yang Shi
2019-04-11 16:06 ` Dave Hansen
2019-04-15 22:06 ` Yang Shi
2019-04-15 22:13 ` Dave Hansen
2019-04-15 22:23 ` Yang Shi
2019-04-11 3:56 ` [v2 PATCH 8/9] mm: vmscan: add page demotion counter Yang Shi
2019-04-11 3:56 ` [v2 PATCH 9/9] mm: numa: add page promotion counter Yang Shi
2019-04-11 14:28 ` [v2 RFC PATCH 0/9] Another Approach to Use PMEM as NUMA Node Dave Hansen
2019-04-12 8:47 ` Michal Hocko
2019-04-16 0:09 ` Yang Shi
2019-04-16 7:47 ` Michal Hocko
2019-04-16 14:30 ` Dave Hansen
2019-04-16 14:39 ` Michal Hocko
2019-04-16 15:46 ` Dave Hansen
2019-04-16 18:34 ` Michal Hocko
2019-04-16 15:33 ` Zi Yan
2019-04-16 15:55 ` Dave Hansen
2019-04-16 16:12 ` Zi Yan [this message]
2019-04-16 19:19 ` Yang Shi
2019-04-16 21:22 ` Dave Hansen
2019-04-16 21:59 ` Yang Shi
2019-04-16 23:04 ` Dave Hansen
2019-04-16 23:17 ` Yang Shi
2019-04-17 15:13 ` Keith Busch
2019-04-17 9:23 ` Michal Hocko
2019-04-17 15:23 ` Keith Busch
2019-04-17 15:39 ` Michal Hocko
2019-04-17 15:37 ` Keith Busch
2019-04-17 16:39 ` Michal Hocko
2019-04-17 17:26 ` Yang Shi
2019-04-17 17:29 ` Keith Busch
2019-04-17 17:51 ` Michal Hocko
2019-04-18 16:24 ` Yang Shi
2019-04-17 17:13 ` Dave Hansen
2019-04-17 17:57 ` Michal Hocko
2019-04-18 18:16 ` Keith Busch
2019-04-18 19:23 ` Yang Shi
2019-04-18 21:07 ` Zi Yan
2019-04-16 23:18 ` Yang Shi
2019-04-17 9:17 ` Michal Hocko
2019-05-01 6:43 ` Fengguang Wu
2019-04-17 20:43 ` Yang Shi
2019-04-18 9:02 ` Michal Hocko
2019-05-01 5:20 ` Fengguang Wu
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=027AE219-8C81-47DC-A241-4209C3F656A0@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=fan.du@intel.com \
--cc=fengguang.wu@intel.com \
--cc=hannes@cmpxchg.org \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=riel@surriel.com \
--cc=yang.shi@linux.alibaba.com \
--cc=ying.huang@intel.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).