[RFC PATCH v2 0/9] mm/damon: make allow filters after reject filters useful and intuitive

[RFC PATCH v2 0/9] mm/damon: make allow filters after reject filters useful and intuitive

[SeongJae Park]

DAMOS filters do allow or reject elements of memory for given DAMOS
scheme only if those match the filter criterias.  For elements that
don't match any DAMOS filter, 'allowing' is the default behavior.  This
makes allow-filters that don't have any reject-filter after them
meaningless sources of overhead.  The decision was made to keep the
behavior consistent with that before the introduction of allow-filters.
This, however, makes usage of DAMOS filters confusing and inefficient.
There is an apparently more intuitive behavior for the case.  If there
is no filter at all or the last filter is a reject filter, allowing by
default.

Update the filtering logic to work in the way.  Decide the default
behavior as the opposite of the last isntalled filter.  If it is an
allow filter, reject by default.  If it is a reject filter or no filter
is installed at all, allow by default.

Note that this is changing the old behavior.  But the old behavior for
the problematic filter combination was definitely confusing, inefficient
and anyway useless.  Also, the behavior has relatively recently
introduced.  It is difficult to anticipate any user that depends on the
behavior.  Hence this is not a user-breaking behavior change but an
obvious improvement.

Changes from RFC v1
(https://lore.kernel.org/20250220193509.36379-1-sj@kernel.org)
- Set default behavior on core layer filtering stage as allow if any ops
  layer filter exists.
- Wordsmith commit messages
- Rebase on latest mm-unstable

SeongJae Park (9):
  mm/damon/core: introduce damos->ops_filters
  mm/damon/paddr: support ops_filters
  mm/damon/core: support committing ops_filters
  mm/damon/core: put ops-handled filters to damos->ops_filters
  mm/damon/paddr: support only damos->ops_filters
  mm/damon: add default allow/reject behavior fields to struct damos
  mm/damon/core: set damos_filter default allowance behavior based on
    installed filters
  mm/damon/paddr: respect ops_filters_default_reject
  Docs/mm/damon/design: update for changed filter-default behavior

 Documentation/mm/damon/design.rst | 10 ++--
 include/linux/damon.h             | 11 ++++
 mm/damon/core.c                   | 90 +++++++++++++++++++++++++++++--
 mm/damon/paddr.c                  |  8 +--
 4 files changed, 105 insertions(+), 14 deletions(-)


base-commit: d5c41979a39f18ccd660b25eb79e805eb5442e18
-- 
2.39.5

[RFC PATCH v2 9/9] Docs/mm/damon/design: update for changed filter-default behavior

[SeongJae Park]

Update the design documentation for changed DAMOS filters default
allowance behaviors.

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 Documentation/mm/damon/design.rst | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 5af991551a86..ffea744e4889 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -581,9 +581,10 @@ When multiple filters are installed, the group of filters that handled by the
 core layer are evaluated first.  After that, the group of filters that handled
 by the operations layer are evaluated.  Filters in each of the groups are
 evaluated in the installed order.  If a part of memory is matched to one of the
-filter, next filters are ignored.  If the memory passes through the filters
+filter, next filters are ignored.  If the part passes through the filters
 evaluation stage because it is not matched to any of the filters, applying the
-scheme's action to it is allowed, same to the behavior when no filter exists.
+scheme's action to it depends on the last filter's allowance type.  If the last
+filter was for allowing, the part of memory will be rejected, and vice versa.
 
 For example, let's assume 1) a filter for allowing anonymous pages and 2)
 another filter for rejecting young pages are installed in the order.  If a page
@@ -595,11 +596,6 @@ second reject-filter blocks it.  If the page is neither anonymous nor young,
 the page will pass through the filters evaluation stage since there is no
 matching filter, and the action will be applied to the page.
 
-Note that the action can equally be applied to memory that either explicitly
-filter-allowed or filters evaluation stage passed.  It means that installing
-allow-filters at the end of the list makes no practical change but only
-filters-checking overhead.
-
 Below ``type`` of filters are currently supported.
 
 - Core layer handled
-- 
2.39.5