linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Bharata B Rao <bharata@amd.com>
Cc: David Rientjes <rientjes@google.com>,
	John Hubbard <jhubbard@nvidia.com>, Zi Yan <ziy@nvidia.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>,
	linux-mm@kvack.org, Adam Manzanares <a.manzanares@samsung.com>
Subject: Re: [RFC] Memory tiering kernel alignment
Date: Thu, 29 Feb 2024 10:23:43 -0800	[thread overview]
Message-ID: <20240229182343.74268-1-sj@kernel.org> (raw)
In-Reply-To: <781b3a7a-082d-46c1-a31a-1484c62123ac@amd.com>

On Thu, 29 Feb 2024 09:31:02 +0530 Bharata B Rao <bharata@amd.com> wrote:

> On 29-Feb-24 7:34 AM, Davidlohr Bueso wrote:
> > On Thu, 25 Jan 2024, David Rientjes wrote:
> > 
> >> Some recent discussions have proven that there is widespread interest in
> >> some very foundational topics for this technology such as:
> >>
> >> - Decoupling CPU balancing from memory balancing (or obsoleting CPU
> >>   balancing entirely)
> >>
> >>   + John Hubbard notes this would be useful for GPUs:
> >>
> >>      a) GPUs have their own processors that are invisible to the kernel's
> >>         NUMA "which tasks are active on which NUMA nodes" calculations,
> >>         and
> >>
> >>      b) Similar to where CXL is generally going, we have already built
> >>         fully memory-coherent hardware, which include memory-only NUMA
> >>         nodes.
> >>
> >> - In-kernel hot memory abstraction, informed by hardware hinting drivers
> >>   (incl some architectures like Power10), usable as a NUMA Balancing
> >>   backend for promotion and other areas of the kernel like transparent
> >>   hugepage utilization
> > 
> > Regarding the hardware counters, can/will CPU vendors provide something
> > better for what is currently there for PEBS/IBS - which needs a lot of
> > stat crunching to make it useful for hot page detection.
> 
> IBS works independent of PMCs and reports useful information like the
> virtual and physical address of the access, precise IP, Data Source
> info (like cache, DRAM, External memory/CXL etc), remote node indication
> etc. Hence it doesn't really need stat crunching.
> 
> However it captures and reports access information based on sampling
> and I have seen that the best sampling interval isn't always good enough
> to match the number of accesses captured by software based mechanism
> like NUMA balancing.

This is same for sampling methods using time interval such as DAMON.  I'm
trying to make a sort of automatic tuning of such intervals for DAMON based on
realtime monitoring results and real request from users.  For example, if the
user want to find hottest memory region of X % of the total memory, we could
draw hotness histogram of the memory and get some clue about if the current
sampling interval is too large or small.  Just a vague idea.  I haven't spent
time for this topic so far.

Since DAMON is designed to be easy to be extended with multiple access check
methods including hardware features like IBS, I think the DAMON level
auto-tuning might help in this case.


Thanks,
SJ

> 
> Regards,
> Bharata.
> 
> 


      reply	other threads:[~2024-02-29 18:23 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
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 [this message]

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=20240229182343.74268-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=a.manzanares@samsung.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=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=weixugc@google.com \
    --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