linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Wei Xu <weixugc@google.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	Linux MM <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Yang Shi <shy828301@gmail.com>,
	David Rientjes <rientjes@google.com>,
	Huang Ying <ying.huang@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH 02/10] mm/numa: automatically generate node migration order
Date: Wed, 14 Apr 2021 10:08:54 +0200	[thread overview]
Message-ID: <20210414080849.GA20886@linux> (raw)
In-Reply-To: <CAAPL-u8Jk-i-9-iSnU7_nb-k2ZMqdRk5c88d-M6Bi1rfv4kSLQ@mail.gmail.com>

On Fri, Apr 09, 2021 at 08:07:08PM -0700, Wei Xu wrote:
> On Thu, Apr 1, 2021 at 11:35 AM Dave Hansen <dave.hansen@linux.intel.com> wrote:
> > + * When Node 0 fills up, its memory should be migrated to
> > + * Node 1.  When Node 1 fills up, it should be migrated to
> > + * Node 2.  The migration path start on the nodes with the
> > + * processors (since allocations default to this node) and
> > + * fast memory, progress through medium and end with the
> > + * slow memory:
> > + *
> > + *     0 -> 1 -> 2 -> stop
> > + *     3 -> 4 -> 5 -> stop
> > + *
> > + * This is represented in the node_demotion[] like this:
> > + *
> > + *     {  1, // Node 0 migrates to 1
> > + *        2, // Node 1 migrates to 2
> > + *       -1, // Node 2 does not migrate
> > + *        4, // Node 3 migrates to 4
> > + *        5, // Node 4 migrates to 5
> > + *       -1} // Node 5 does not migrate
> > + */
> 
> In this example, if we want to support multiple nodes as the demotion
> target of a source node, we can group these nodes into three tiers
> (classes):
> 
> fast class:
> 0 -> {1, 4}  // 1 is the preferred
> 3 -> {4, 1}  // 4 is the preferred
> 
> medium class:
> 1 -> {2, 5}  // 2 is the preferred
> 4 -> {5, 2}  // 5 is the preferred
> 
> slow class:
> 2 -> stop
> 5 -> stop

Hi Wei Xu,

I have some questions about it

Fast class/memory are pictured as those nodes with CPUs, while Slow class/memory
are PMEM, right?
Then, what stands for medium class/memory?

In Dave's example, list is created in a way that stays local to the socket,
and we go from the fast one to the slow one.
In yours, lists are created taking the fastest nodes from all sockets and
we work our way down, which means have cross-socket nodes in the list.
How much of a penalty is that?

And while I get your point, I am not sure if that is what we pretend here.
This patchset aims to place cold pages that are about to be reclaim in slower
nodes to give them a second chance, while your design seems more to have kind
of different memory clases and be able to place applications in one of those tiers
depending on its demands or sysadmin-demand.

Could you expand some more?

-- 
Oscar Salvador
SUSE L3

  reply	other threads:[~2021-04-14  8:11 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01 18:32 [PATCH 00/10] [v7][RESEND] Migrate Pages in lieu of discard Dave Hansen
2021-04-01 18:32 ` [PATCH 01/10] mm/numa: node demotion data structure and lookup Dave Hansen
2021-04-08  8:03   ` Oscar Salvador
2021-04-08 21:29     ` Dave Hansen
2021-04-09  5:32   ` Wei Xu
2021-04-01 18:32 ` [PATCH 02/10] mm/numa: automatically generate node migration order Dave Hansen
2021-04-08  8:26   ` Oscar Salvador
2021-04-08 21:51     ` Dave Hansen
2021-04-09  8:17       ` Oscar Salvador
2021-04-10  3:07   ` Wei Xu
2021-04-14  8:08     ` Oscar Salvador [this message]
2021-04-14  8:11       ` Oscar Salvador
2021-04-14  8:12       ` David Hildenbrand
2021-04-14  8:14         ` Oscar Salvador
2021-04-14  8:20           ` David Hildenbrand
2021-04-15  4:07       ` Wei Xu
2021-04-15 15:35         ` Dave Hansen
2021-04-15 20:25           ` Wei Xu
2021-04-01 18:32 ` [PATCH 03/10] mm/migrate: update node demotion order during on hotplug events Dave Hansen
2021-04-08  9:52   ` Oscar Salvador
2021-04-09 10:14     ` Oscar Salvador
2021-04-09 10:15       ` Oscar Salvador
2021-04-09 18:59       ` David Hildenbrand
2021-04-12  7:19         ` Oscar Salvador
2021-04-12  9:19           ` David Hildenbrand
2021-04-01 18:32 ` [PATCH 04/10] mm/migrate: make migrate_pages() return nr_succeeded Dave Hansen
2021-04-01 22:39   ` Wei Xu
     [not found]   ` <CAAPL-u-o-M2T25xBtSoipYjUnu+3aJNcJ9uS84yKaAnbrXpefw@mail.gmail.com>
2021-04-01 23:21     ` Dave Hansen
2021-04-08 10:14   ` Oscar Salvador
2021-04-08 17:26     ` Yang Shi
2021-04-08 18:17       ` Oscar Salvador
2021-04-08 18:21         ` Oscar Salvador
2021-04-08 20:40         ` Yang Shi
2021-04-09  5:06           ` Oscar Salvador
2021-04-09  5:43             ` Wei Xu
2021-04-09 15:43             ` Yang Shi
2021-04-09 15:50         ` Dave Hansen
2021-04-09 18:47           ` Wei Xu
2021-04-09 20:10           ` Yang Shi
2021-04-01 18:32 ` [PATCH 05/10] mm/migrate: demote pages during reclaim Dave Hansen
2021-04-01 20:01   ` Yang Shi
2021-04-01 22:58     ` Dave Hansen
2021-04-08 10:47   ` Oscar Salvador
2021-04-10  3:35   ` Wei Xu
2021-04-01 18:32 ` [PATCH 06/10] mm/vmscan: add page demotion counter Dave Hansen
2021-04-10  3:40   ` Wei Xu
2021-04-01 18:32 ` [PATCH 07/10] mm/vmscan: add helper for querying ability to age anonymous pages Dave Hansen
2021-04-07 18:40   ` Wei Xu
2021-04-09  8:31     ` Oscar Salvador
2021-04-01 18:32 ` [PATCH 08/10] mm/vmscan: Consider anonymous pages without swap Dave Hansen
2021-04-02  0:55   ` Wei Xu
2021-04-01 18:32 ` [PATCH 09/10] mm/vmscan: never demote for memcg reclaim Dave Hansen
2021-04-02  0:18   ` Wei Xu
2021-04-01 18:32 ` [PATCH 10/10] mm/migrate: new zone_reclaim_mode to enable reclaim migration Dave Hansen
2021-04-01 20:06   ` Yang Shi
2021-04-10  4:10   ` Wei Xu
2021-04-16 12:35 ` [PATCH 00/10] [v7][RESEND] Migrate Pages in lieu of discard Michal Hocko
2021-04-16 14:26   ` Dave Hansen
2021-04-16 15:02     ` Michal Hocko
2021-04-21  2:39       ` Huang, Ying
2021-05-07  6:14       ` Huang, Ying
2021-06-11  5:50       ` Huang, Ying
  -- strict thread matches above, loose matches on Subject: below --
2021-03-04 23:59 [PATCH 00/10] [v6] " Dave Hansen
2021-03-04 23:59 ` [PATCH 02/10] mm/numa: automatically generate node migration order Dave Hansen
2021-03-08 23:59   ` Yang Shi

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=20210414080849.GA20886@linux \
    --to=osalvador@suse.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=shy828301@gmail.com \
    --cc=weixugc@google.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).