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