All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Ravi Jonnalagadda <ravis.opensrc@gmail.com>
Cc: SeongJae Park <sj@kernel.org>,
	damon@lists.linux.dev, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	akpm@linux-foundation.org, corbet@lwn.net, bijan311@gmail.com,
	ajayjoshi@micron.com, honggyu.kim@sk.com, yunjeong.mun@sk.com
Subject: Re: [RFC PATCH v3 0/4] mm/damon: Introduce node_eligible_mem_bp and node_ineligible_mem_bp Quota Goal Metrics
Date: Wed, 25 Feb 2026 16:52:46 -0800	[thread overview]
Message-ID: <20260226005248.7509-1-sj@kernel.org> (raw)
In-Reply-To: <CALa+Y17HPOxpLF41+Jn-fHqu7s4YUzgsFKdhD9MsN=wCop_kRw@mail.gmail.com>

On Wed, 25 Feb 2026 10:19:11 -0800 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:

> On Mon, Feb 23, 2026 at 9:36 PM SeongJae Park <sj@kernel.org> wrote:
> >
> > Hello Ravi,
> >
> > On Mon, 23 Feb 2026 12:32:28 +0000 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> >
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset=UTF-8
> > > Content-Transfer-Encoding: 8bit
> > >
> > > This series introduces two new DAMON quota goal metrics for controlling
> > > memory migration in heterogeneous memory systems (e.g., DRAM and CXL
> > > memory tiering) using physical address (PA) mode monitoring.
> >
> > Thank you for keep working on and sharing this :)
> 
> Thank you for the detailed review!

My pleasure!

[...]
> > > - Added PA-mode detection lag compensation cache (see dedicated section
> > >   below for design details).
> >
> > I'm not very sure if this is really needed, though.  I'll leave comment on the
> > dedicated section below.
> 
> Understood. I consciously separated the cache implementation (patch 4)
> from the core metrics (patch 3) because the cache is ONE possible approach to
> handle detection lag - not necessarily THE approach. My goal was to share
> what was needed to achieve equilibrium with my synthetic benchmark
> workload (multiload),
> while making it clear that the cache mechanism could be dropped or
> replaced with alternatives.

That was indeed helpful for reviewing, thank you!

> 
> >
> > >
> > > - Added fix for esz=0 quota bypass that allowed unlimited migration when
> > >   goal was achieved.
> > >
> > > - Added fix for goal_tuner sysfs setting being ignored due to
> > >   damon_new_scheme() always defaulting to CONSIST.
> >
> > Thank you for finding and fixing these issues in my previously shared RFC patch
> > series!  I left a few comments to the patches.  In short, the second fix looks
> > good and I will add that to the next revision of my RFC patch series, if you
> > don't mind.  For the first fix, I'd like to take more time on thinking more
> > cleaner solution.
> 
> Sounds good. Please go ahead and incorporate the goal_tuner fix into
> your series.
> Happy to test whatever approach you come up with for the esz=0 issue.

Thank you, I will do!

[...]
> > > In PA-mode, when pages are migrated:
> > > 1. Source node detection drops immediately (pages are gone)
> > > 2. Target node detection increases slowly (new addresses need sampling)
> >
> > I agree.  And this is not what I clearly expected during the previous
> > discussion.  Thank you for sharing this issue.
> 
> I'm glad this observation is useful. It was something I discovered during
> testing that wasn't obvious until I looked at the trace data closely.

Thank you for sharing the pain point.  I recently added a few more DAMOS
tracepoints motivated by our offline discussion.  I'm planning to add better
supports of those in DAMON user-space tool.  Knowing this kind of pain points
is essential and useful at improving DAMON, thank you!

[...]
> > I will leave more comments to the patch implementing this.  But this seems too
> > much at the current stage, unless there are clear test results showing its
> > needs.  I'd recommend proceeding without this, and later revisit if the problem
> > becomes clearly significant.
> 
> I agree. Let's drop patch 4 for now and focus on getting the core
> metrics merged.
> The cache mechanism can be revisited later if real-world usage shows
> it's needed.

Thank you for flexibly accepting my suggestion!

[...]
> > I'm yet to further reply to the fourth patch, but I hope my comments be worthy
> > :)
> >
> 
> Very much so! Your feedback has been invaluable in shaping this work. :-)

More than exciting to hear that :D

> 
> I'm currently on a break and will be back after March 10th. Once I return,
> I'll send the updated patch 3 and share test results with CONSIST
> tuner.

Sounds perfect, I hope you to have great break!


Thanks,
SJ

[...]

      reply	other threads:[~2026-02-26  0:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 12:32 [RFC PATCH v3 0/4] mm/damon: Introduce node_eligible_mem_bp and node_ineligible_mem_bp Quota Goal Metrics Ravi Jonnalagadda
2026-02-23 12:32 ` [RFC PATCH v3 1/4] mm/damon/sysfs: set goal_tuner after scheme creation Ravi Jonnalagadda
2026-02-24  1:40   ` SeongJae Park
2026-02-25 18:23     ` Ravi Jonnalagadda
2026-02-26  0:53       ` SeongJae Park
2026-02-27  2:04         ` SeongJae Park
2026-02-23 12:32 ` [RFC PATCH v3 2/4] mm/damon: fix esz=0 quota bypass allowing unlimited migration Ravi Jonnalagadda
2026-02-24  1:54   ` SeongJae Park
2026-02-25 18:28     ` Ravi Jonnalagadda
2026-02-26  0:54       ` SeongJae Park
2026-02-23 12:32 ` [RFC PATCH v3 3/4] mm/damon: add node_eligible_mem_bp and node_ineligible_mem_bp goal metrics Ravi Jonnalagadda
2026-02-24  4:27   ` SeongJae Park
2026-02-25 18:46     ` Ravi Jonnalagadda
2026-02-26  0:57       ` SeongJae Park
2026-02-23 12:32 ` [RFC PATCH v4 4/4] mm/damon: add PA-mode cache for eligible memory detection lag Ravi Jonnalagadda
2026-02-24  5:54   ` SeongJae Park
2026-02-25 18:58     ` Ravi Jonnalagadda
2026-02-26  0:59       ` SeongJae Park
2026-02-24  5:36 ` [RFC PATCH v3 0/4] mm/damon: Introduce node_eligible_mem_bp and node_ineligible_mem_bp Quota Goal Metrics SeongJae Park
2026-02-25 18:19   ` Ravi Jonnalagadda
2026-02-26  0:52     ` 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=20260226005248.7509-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=ajayjoshi@micron.com \
    --cc=akpm@linux-foundation.org \
    --cc=bijan311@gmail.com \
    --cc=corbet@lwn.net \
    --cc=damon@lists.linux.dev \
    --cc=honggyu.kim@sk.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ravis.opensrc@gmail.com \
    --cc=yunjeong.mun@sk.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.