Re: [RFC/Discussion] mm/damon: Helping with alternative for watermarks

Liew Rui Yan <[email protected]>
Newsgroups dev.linux.lists.damon,org.kvack.linux-mm
Message-ID <[email protected]>
On Mon, 17 Aug 2026 06:57:42 -0700 SJ Park <[email protected]> wrote:

> On Mon, 17 Aug 2026 16:39:23 +0800 Liew Rui Yan <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.