Re: [PATCH 2/2] mm/damon: skip deactivated schemes in watermark checks and add fallback sleep

SJ Park <[email protected]>
Newsgroups dev.linux.lists.damon,org.kvack.linux-mm
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

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