Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Liew Rui Yan <aethernet65535@gmail.com>
To: sj@kernel.org
Cc: aethernet65535@gmail.com, damon@lists.linux.dev,
	gutierrez.asier@huawei-partners.com, linux-mm@kvack.org
Subject: Re: [RFC/Discussion] mm/damon: Helping with alternative for watermarks
Date: Fri, 21 Aug 2026 22:16:54 +0800	[thread overview]
Message-ID: <20260821141654.203418-1-aethernet65535@gmail.com> (raw)
In-Reply-To: <20260817135742.75706-1-sj@kernel.org>

On Mon, 17 Aug 2026 06:57:42 -0700 SJ Park <sj@kernel.org> wrote:

> On Mon, 17 Aug 2026 16:39:23 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> > 1. Why use Watermarks? And what was the problem?
> > 
> > I now understand why we do not need better Watermarks, so my answer is
> > based on my previous thought.
> > 
> > I used Watermarks primarily because it is the only mechanism I know for
> > stopping/running a Scheme.  The problem is it can only monitor MemFree.
> 
> Thank you for clarifying.  I'd like to go one step further.  What is the
> initial problem?  Why you need the automatic proactive reclamation?  Do you
> have some data showing the problem?

To be honest, I have not encountered any problems, and I do not have any
rigorous data.  I simply using DAMON to try proactive reclamation, and
see if it would cause any serious issues.  So far, it has not; it has
almost no noticeable negative impact on daily use.

> 
> > 
> > 2. How exactly the page cache becomes a problem for you?
> > 
> > After prolonged computer use, the page cache can become full.
> > DAMON_RECLAIM might then mistakenly assume there is slight memory
> > pressure and reclaim those cached pages.  Unnecessary page cache
> > reclamation can incur unnecessary overhead.
> 
> Thank you for sharing this.  I can theoretically understand the issue.  Maybe
> you are concerned if page cache is too aggressively reclaimed and therefore if
> file io becomes slow.  But I'm not really sure if it is only theoretical or
> real.  Since the proactive reclamation reclaims coldest page first, and because
> it works for not only page cache, the performance impact might not that big in
> real.  Do you have some data showing the problem?

This is currently only theoretical.  I also think that the performance
impact will likely be minimal.  I think adding a MemAvailable option
provides certainty, if users know for sure that their devices will not
lag when MemFree is low, but will when MemAvailable is low, then they
can choose the option that best suits their device based on their own
situation.

However, since DAMOS Quota already supports checking current_value from
user input, and I cannot yet prove whether this option can bring
improvement in any workload, I think we can disregard whether to add
this new option for now.

> 
> > 
> > 3. Has the MemAvailable based one solved your problem?
> > 
> > Yes, using MemAvailable as a watermarks/DAMOS Quota metric can avoid a
> > lot of unnecessary memory reclamation.
> 
> Great to hear that.  I'm curious if you have some data showing the improvement.

While I do not have rigorous data to demonstrate any improvement yet, I
appreciate your guidance on this.

I will continue exploring DAMON on my end, and I might send out some
patches later regarding a few logical issues I noticed in the code.
Thank you again for your time and answers.

Best regards,
Rui Yan


  reply	other threads:[~2026-08-21 14:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14  8:47 [RFC/Discussion] mm/damon: Helping with alternative for watermarks Liew Rui Yan
2026-08-14 14:54 ` SJ Park
2026-08-17  8:39   ` Liew Rui Yan
2026-08-17 13:57     ` SJ Park
2026-08-21 14:16       ` Liew Rui Yan [this message]
2026-08-21 23:43         ` SJ 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=20260821141654.203418-1-aethernet65535@gmail.com \
    --to=aethernet65535@gmail.com \
    --cc=damon@lists.linux.dev \
    --cc=gutierrez.asier@huawei-partners.com \
    --cc=linux-mm@kvack.org \
    --cc=sj@kernel.org \
    /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