Skip to content

RFC mm/damon: make allow filters after reject filters useful and intuitive

SeongJae Park damon linux-doc linux-mm lkml 2 versions – In review

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v2 RFC Latest9 patches 2 repliesIn review
  2. v1 RFC9 patches 1 replySuperseded

Changes in v2 from the cover letter

(https://lore.kernel.org/[email protected])
- Set default behavior on core layer filtering stage as allow if any ops layer filter exists.
- Wordsmith commit messages
- Rebase on latest mm-unstable

Patches in v2 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/9mm/damon/core: introduce damos->ops_filtersinclude/linux/damon.h mm/damon/core.c+9 -00 replies
2/9mm/damon/paddr: support ops_filtersmm/damon/paddr.c+12 -00 replies
3/9mm/damon/core: support committing ops_filtersmm/damon/core.c+39 -10 replies
4/9mm/damon/core: put ops-handled filters to damos->ops_filtersmm/damon/core.c+16 -10 replies
5/9mm/damon/paddr: support only damos->ops_filtersmm/damon/paddr.c+0 -120 replies
6/9mm/damon: add default allow/reject behavior fields to struct damosinclude/linux/damon.h+3 -00 replies
7/9mm/damon/core: set damos_filter default allowance behavior based on installed filtersmm/damon/core.c+32 -22 replies
8/9mm/damon/paddr: respect ops_filters_default_rejectmm/damon/paddr.c+1 -10 replies
9/9Docs/mm/damon/design: update for changed filter-default behaviorDocumentation/mm/damon/design.rst+3 -70 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.

Read the v2 thread

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

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/[email protected])
- 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

Signature · 1 line
2.39.5