All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	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: Thu, 25 Jan 2024 16:16:18 -0800	[thread overview]
Message-ID: <20240126001618.13281-1-sj@kernel.org> (raw)
In-Reply-To: <e351526b-0872-afcb-4eb7-a3dd6242f9f9@google.com>

On Thu, 25 Jan 2024 13:37:02 -0800 (PST) David Rientjes <rientjes@google.com> wrote:

> 
> On Thu, 25 Jan 2024, Matthew Wilcox wrote:
> 
> > On Thu, Jan 25, 2024 at 12:04:37PM -0800, David Rientjes wrote:
> > > On Thu, 25 Jan 2024, Matthew Wilcox wrote:
> > > > On Thu, Jan 25, 2024 at 10:26:19AM -0800, 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
> 
> I could go code all of this up and spend an enormous amount of time doing 
> so only to get NAKed by somebody because I'm ripping out their critical 
> use case that I just didn't know about :)  There's also the question of 
> whether DAMON should be the source of truth for this or it should be 
> decoupled.

I wouldn't dare to say DAMON should be the source of truth, but I hope DAMON to
be somewhat useful.  DAMON is designed to be able to be easily extended[1] for
various access monitoring / memory management primitives including hardware
features.  DAMOS of today provides a feature called filter[2], which allows
applying specific operations to specific pages depending on their
non-access-pattern information including type (anon vs file-backed) and which
memcg it belongs to.  Hence I think DAMON might be able to be used for a few of
above cases.

[1] https://docs.kernel.org/mm/damon/design.html#configurable-operations-set
[2] https://docs.kernel.org/mm/damon/design.html#filters


Thanks,
SJ

[...]


  parent reply	other threads:[~2024-01-26  0:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <tsnp3a6oxglx2siv7aoplo665k7xsigkqtpfm5yiu2r3wvys26@3vntgau4t2gv>
2024-01-25 18:26 ` [RFC] Memory tiering kernel alignment 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 [this message]
2024-01-26 21:06           ` Christoph Lameter (Ampere)
2024-01-26 23:03             ` Gregory Price
2024-01-28 20:15           ` David Rientjes
2024-01-29 10:27         ` David Hildenbrand
2024-01-26 20:41     ` Christoph Lameter (Ampere)
2024-01-26  0:04   ` SeongJae Park
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=20240126001618.13281-1-sj@kernel.org \
    --to=sj@kernel.org \
    --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=rientjes@google.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.