From: SJ Park <sj@kernel.org>
To: Liew Rui Yan <aethernet65535@gmail.com>
Cc: SJ Park <sj@kernel.org>,
	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 16:43:18 -0700
Message-ID: <20260821234319.87475-1-sj@kernel.org>
In-Reply-To: <20260821141654.203418-1-aethernet65535@gmail.com>
References: 
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

On Fri, 21 Aug 2026 22:16:54 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> 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.

Thank you for clarifying.  Also appreciate your test of DAMON.  I'm curious if
you noticed any positive impact, too.

> 
> > 
> > > 
> > > 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.

I understand it will allow users to tune the system for target MemAvaialble
value.  But, I fail at understanding what is the advantage of it, even in
theory.  It would be nice if we can have a clear example scenario that shows
advantage of MemAvailable based watermarks compared to MemFree based one.

> 
> 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 wouldn't say we can never add MemAvaialble based watermarks until we have
proving data.  But, I think we definitely need a clear theory to start a
discussion.

> 
> 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.

I'm looking forward to the patches!

> Thank you again for your time and answers.

Thank you, too!

> 
> Best regards,
> Rui Yan


Thanks,
SJ