Re: [PATCH 2/2] mm/damon: skip deactivated schemes in watermark checks and add fallback sleep
SJ Park <[email protected]>
| Newsgroups | org.kvack.linux-mm,dev.linux.lists.damon |
|---|---|
| Message-ID | <[email protected]> |
On Sun, 9 Aug 2026 05:55:54 +0800 Liew Rui Yan <[email protected]> wrote: > Hi SJ, > > On Fri, 7 Aug 2026 07:07:39 -0700 SJ Park <[email protected]> wrote: > > > This is an intended implementation. > > > > When all schemes are deactivated by watermarks, DAMON stops monitoring. It was > > implemented in the way because we didn't want DAMON consumes system resource in > > the case. But, later it turned out DAMON's resource consumption is really > > negligible. Rather, it is turned out that it makes DAMON runs with stale > > history when it is activated again. Particularly, regions have 'age' and their > > start/end addresses that was emerged before the deactivation. Those are > > meaningless and could even cause wrong DAMOS decisions. > > > > We don't want that anymore. For a case the user really want DAMON completely > > stops, we introduced 'pause'. For max_nr_snapshot-based deactivation, we don't > > intend to completely stop DAMON. > > > > Maybe the documentation can be updated to further clarify this. > > Wait, according to the documentation and the code, DAMON will still stop > monitoring when all schemes is deactivated. That's correct. [...] > Should this be changed to monitoring will not stop? No. The change you mentioning will be unexpected behavioral change. > > Also this patch (0002) add a new function named damos_is_deactivated(), > it checks both wmarks.activated and max_nr_snapshot conditions, and I > replace the wmarks.activated-only with this new function. Let's distinguish watermarks based deactivation and max_nr_snapshots based deactivation. They are completely different things and have different behaviors. The current documentation may confused you. > > I am sorry if my commit message has caused you any misunderstanding. No worry. The current poor documentation is the one to blame in my opinion. Thanks, SJ [...]