From: SeongJae Park <sj@kernel.org>
To: Liew Rui Yan <aethernet65535@gmail.com>
Cc: SeongJae Park <sj@kernel.org>, damon@lists.linux.dev, linux-mm@kvack.org
Subject: Re: [RFC PATCH] mm/damon/reclaim: add 'available' memory as an optional watermarks metric
Date: Fri, 26 Jun 2026 07:18:18 -0700 [thread overview]
Message-ID: <20260626141819.86269-1-sj@kernel.org> (raw)
In-Reply-To: <20260626081038.46569-1-aethernet65535@gmail.com>
Hi Liew,
Thank you for this patch!
On Fri, 26 Jun 2026 16:10:38 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
> Problem
> =======
>
> Currently, DAMON's watermarks metric is calculated based on the
> proportion of the system's free memory.
>
> However, on devices like Android, the system typically maintains a very
> low amount of free memory, even when the available memory is abundant.
> This causes DAMON_RECLAIM to prematurely or aggressive trigger memory
> reclamation, thereby increasing the risk of page refaults.
>
> Solution
> ========
>
> Introduce a new sysfs parameter 'memrate_type' to DAMON_RECLAIM. Users
> can switch DAMON's watermark metric evaluation to be based on available
> memory by writing 'available' to this parameter and commit the change.
How about using DAMOS quota with its aim-based auto-tuning, instead?
I developed DAMOS watermarks and quota as safe guards of DAMOS. In more
detail, DAMOS quota is for restricting only resource usage of DAMOS.
Meanwhile, watermarks is for restricting resource usage of both DAMON and
DAMOS. That is, when the watermarks condition is met, not only DAMOS but also
DAMON is completely paused. Also, watermarks feature was considered smarter
than quota, because it is a kind of auto-tuning.
However, it turned out completely turning DAMON off is not a very good idea,
because it drops monitoring results when the watermarks condition is met and
therefore completely stops DAMON and DAMOS. It drops the region shapes and
'age' information. Especially, 'age' of some regions commonly cumulated up to
hours or even days. Dropping that was a problem in production use cases.
Meanwhile, we introduced aim-oriented DAMOS quota auto-tuning (a.k.a DAMOS
quota goal). It made DAMOS quota smarter and easier to extend than watermarks.
Nowadays, users can also pause and resume [1] DAMON/DAMOS without losing the
monitoring information when they want.
So, I personally don't encourage people to use watermarks. Of course, I may
missing some problems in alternatives. Hence I'm asking the question to you.
How about using DAMOS quota with its aim-based auto-tuning, instead? If you
cannot, could you share more details?
I'll hold reviewing the code until this high level discussion is resolved.
[1] https://lore.kernel.org/20260427151231.113429-1-sj@kernel.org
Thanks,
SJ
[...]
prev parent reply other threads:[~2026-06-26 14:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 8:10 [RFC PATCH] mm/damon/reclaim: add 'available' memory as an optional watermarks metric Liew Rui Yan
2026-06-26 8:24 ` sashiko-bot
2026-06-26 14:18 ` 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=20260626141819.86269-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=aethernet65535@gmail.com \
--cc=damon@lists.linux.dev \
--cc=linux-mm@kvack.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 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.