linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: John Hubbard <jhubbard@nvidia.com>, Zi Yan <ziy@nvidia.com>,
	 Bharata B Rao <bharata@amd.com>,
	Dave Jiang <dave.jiang@intel.com>,
	 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	 "Huang, Ying" <ying.huang@intel.com>,
	Alistair Popple <apopple@nvidia.com>,
	 Christoph Lameter <cl@gentwo.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	 Linus Torvalds <torvalds@linux-foundation.org>,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	Mel Gorman <mgorman@suse.de>,  Jon Grimm <jon.grimm@amd.com>,
	Gregory Price <gourry.memverge@gmail.com>,
	 Brian Morris <bsmorris@google.com>, Wei Xu <weixugc@google.com>,
	 Johannes Weiner <hannes@cmpxchg.org>,
	SeongJae Park <sj@kernel.org>,
	 linux-mm@kvack.org
Subject: Re: [RFC] Memory tiering kernel alignment
Date: Sun, 28 Jan 2024 12:15:38 -0800 (PST)	[thread overview]
Message-ID: <ca03a823-bd53-a8c6-b898-f7658638a03a@google.com> (raw)
In-Reply-To: <e351526b-0872-afcb-4eb7-a3dd6242f9f9@google.com>

On Thu, 25 Jan 2024, David Rientjes wrote:

> This is **exactly** the type of discussion we're looking to have :)
> 
> There are some things that I've chatted informally with folks about that 
> I'd like to bring to the forum:
> 
>  - Decoupling CPU migration from memory migration for NUMA Balancing (or
>    perhaps deprecating CPU migration entirely)
> 
>  - Allowing NUMA Balancing to do migration as part of a kthread 
>    asynchronous to the NUMA hint fault, in kernel context
> 
>  - Abstraction for future hardware devices that can provide an expanded
>    view into page hotness that can be leveraged in different areas of the
>    kernel, including as a backend for NUMA Balanacing to replace NUMA
>    hint faults
> 
>  - Per-container support for configuring balancing and memory migration
> 
>  - Opting certain types of memory into NUMA Balancing (like tmpfs) while
>    leaving other types alone
> 
>  - Utilizing hardware accelerated memory migration as a replacement for
>    the traditional migrate_pages() path when available
> 

It would be absolutely stunning if all of the above is non controversial 
:)

I would imagine that there are some (perhaps strong) opinions polarized 
between "ok, this makes sense" and "ok, this seems crazy" for each one of 
these.  Or, at least, "prove to me that this makes sense."

We can definitely wait for this work group to be formed and then come back 
to the mailing list, but any early feedback on these would be much 
appreciated especially if the opinions are polarized toward the at least 
some of these being on the crazy side.


  parent reply	other threads:[~2024-01-28 20:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-25 18:26 David Rientjes
2024-01-25 18:52 ` Matthew Wilcox
2024-01-25 20:04   ` David Rientjes
2024-01-25 20:19     ` Matthew Wilcox
2024-01-25 21:37       ` David Rientjes
2024-01-25 22:28         ` Gregory Price
2024-01-26  0:16         ` SeongJae Park
2024-01-26 21:06         ` Christoph Lameter (Ampere)
2024-01-26 23:03           ` Gregory Price
2024-01-28 20:15         ` David Rientjes [this message]
2024-01-29 10:27       ` David Hildenbrand
2024-01-26 20:41   ` Christoph Lameter (Ampere)
2024-01-26  0:04 ` SeongJae Park
     [not found] ` <tsnp3a6oxglx2siv7aoplo665k7xsigkqtpfm5yiu2r3wvys26@3vntgau4t2gv>
2024-01-26 14:31   ` John Groves
2024-02-29  2:04 ` Davidlohr Bueso
2024-02-29  4:01   ` Bharata B Rao
2024-02-29 18:23     ` SeongJae Park

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=ca03a823-bd53-a8c6-b898-f7658638a03a@google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=apopple@nvidia.com \
    --cc=bharata@amd.com \
    --cc=bsmorris@google.com \
    --cc=cl@gentwo.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=gourry.memverge@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=jhubbard@nvidia.com \
    --cc=jon.grimm@amd.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=sj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=weixugc@google.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    --cc=ziy@nvidia.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