mm/damon: reposting three reviewed patches
Subsystems (4)
SeongJae Park
maintainercover mm/damon: reposting three reviewed patches
This series reposts patches that were reviewed by the DAMON maintainer but not yet added to mm-new, for more visibility. From their last posted versions, only minor changes including commit subject update,
Reviewed-by: and Acked-by: tags collection, and rebasing to latest mm-new were made by the DAMON maintainer.
Sakurai Shun (1):
Docs/mm/damon/design: fix three typos
Zenghui Yu (1):
Docs/{ABI,admin-guide}/damon: fix various typoes
niecheng (1):
mm/damon/core: clarify next_intervals_tune_sis update path
.../ABI/testing/sysfs-kernel-mm-damon | 2 +- Documentation/admin-guide/mm/damon/usage.rst | 18 +++++++++--------- Documentation/mm/damon/design.rst | 6 +++--- mm/damon/core.c | 3 +++ 4 files changed, 16 insertions(+), 13 deletions(-)
base-commit: f4f9ecd6383da01075a0be8f9c08b82152061fd0
Signature · 1 line
2.47.3
SeongJae Park
maintainerPATCH RESEND 1/3 mm/damon/core: clarify next_intervals_tune_sis update path
From: niecheng <[email protected]>
damon_set_attrs() updates next_aggregation_sis and next_ops_update_sis for online attrs updates, but it does not update next_intervals_tune_sis there.
This can look like a missing update when reading damon_set_attrs() alone, while next_intervals_tune_sis is actually updated in kdamond_fn().
Add a short comment to make this explicit.
---
Changes from v2
- v2: https://lore.kernel.org/D3B0C1F5BB6ADCE4+20260514163751.3399513-1-niecheng1@uniontech.com
- Collect Reviewed-by: tag.
- Rebase to latest mm-new.
Changes from v1
- v1: https://lore.kernel.org/7946CE4E0773AEF7+20260514074846.3258908-1-niecheng1@uniontech.com
- Keep the behavior and clarify it instead.
mm/damon/core.c | 3 +++ 1 file changed, 3 insertions(+)
mm/damon/core.c +3 -0
@@ -909,6 +909,9 @@ int damon_set_attrs(struct damon_ctx *ctx, struct damon_attrs *attrs) attrs->aggr_interval / sample_interval; ctx->next_ops_update_sis = ctx->passed_sample_intervals + attrs->ops_update_interval / sample_interval; +/* +* next_intervals_tune_sis will be updated inside kdamond_fn(). +*/ damon_update_monitoring_results (ctx, attrs, aggregating); ctx->attrs = *attrs;
Signature · 1 line
2.47.3
SeongJae Park
maintainerPATCH RESEND 2/3 Docs/mm/damon/design: fix three typos
In reply to SeongJae ParkFrom: Sakurai Shun <[email protected]>
L140: "unsinged" -> "unsigned"
L371: "sampleing" -> "sampling"
L387: "multipled" -> "multiplied"
---
Changes from v2
- v2: https://lore.kernel.org/[email protected]
- Collect Reviewed-by: and Acked-by: tags.
- Update commit subject prefix.
- Rebase to latest mm-new.
Changes from v1
- v1: https://lore.kernel.org/[email protected]
- Use real author name.
Documentation/mm/damon/design.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Documentation/mm/damon/design.rst +3 -3
@@ -147,7 +147,7 @@ as Idle page tracking does. Address Unit ------------ -DAMON core layer uses ``unsinged long`` type for monitoring target address +DAMON core layer uses ``unsigned long`` type for monitoring target address ranges. In some cases, the address space for a given operations set could be too large to be handled with the type. ARM (32-bit) with large physical address extension is an example. For such cases, a per-operations set
@@ -417,7 +417,7 @@ with theoretical maximum ``nr_accesses``, which can be calculated as ``aggregation interval / sampling interval``. The mechanism calculates the ratio of access events for ``aggrs`` aggregations, -and increases or decrease the ``sampleing interval`` and ``aggregation +and increases or decrease the ``sampling interval`` and ``aggregation interval`` in same ratio, if the observed access ratio is lower or higher than the target, respectively. The ratio of the intervals change is decided in proportion to the distance between current samples ratio and the target ratio.
@@ -433,7 +433,7 @@ The tuning is turned off by default, and need to be set explicitly by the user. As a rule of thumbs and the Parreto principle, 4% access samples ratio target is recommended. Note that Parreto principle (80/20 rule) has applied twice. That is, assumes 4% (20% of 20%) DAMON-observed access events ratio (source) -to capture 64% (80% multipled by 80%) real access events (outcomes). +to capture 64% (80% multiplied by 80%) real access events (outcomes). To know how user-space can use this feature via :ref:`DAMON sysfs interface <sysfs_interface>`, refer to :ref:`intervals_goal
Signature · 1 line
2.47.3
SeongJae Park
maintainerPATCH RESEND 3/3 Docs/{ABI,admin-guide}/damon: fix various typoes
In reply to SeongJae ParkFrom: Zenghui Yu <[email protected]>
``damon_target_idx`` was wrongly written as ``target_idx`` in the docs. Fix it all over the place, as well as the wrong directory count, grammar, etc.
---
Changes from v1
- v1: https://lore.kernel.org/[email protected]
- Collect Reviewed-by: tag.
- Rebase to latest mm-new.
.../ABI/testing/sysfs-kernel-mm-damon | 2 +- Documentation/admin-guide/mm/damon/usage.rst | 18 +++++++++--------- 2 files changed, 10 insertions(+), 10 deletions(-)
Documentation/ABI/testing/sysfs-kernel-mm-damon +1 -1
@@ -452,7 +452,7 @@ Description: If 'hugepage_size' is written to the 'type' file, writing to or reading from this file sets or gets the maximum size of the hugepage for the filter. -What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/<F>/target_idx +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/<F>/damon_target_idx Date: Feb 2025 Contact: SeongJae Park <[email protected]> Description: If 'target' is written to the 'type' file, writing to or
Documentation/admin-guide/mm/damon/usage.rst +9 -9
@@ -97,7 +97,7 @@ comma (","). │ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid,path │ │ │ │ │ │ │ :ref:`watermarks <sysfs_watermarks>`/metric,interval_us,high,mid,low │ │ │ │ │ │ │ :ref:`{core_,ops_,}filters <sysfs_filters>`/nr_filters - │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx,min,max + │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,damon_target_idx,min,max │ │ │ │ │ │ │ :ref:`dests <damon_sysfs_dests>`/nr_dests │ │ │ │ │ │ │ │ 0/id,weight │ │ │ │ │ │ │ :ref:`stats <sysfs_schemes_stats>`/nr_tried,sz_tried,nr_applied,sz_applied,sz_ops_filter_passed,qt_exceeds,nr_snapshots,max_nr_snapshots
@@ -374,7 +374,7 @@ to ``N-1``. Each directory represents each DAMON-based operation scheme. schemes/<N>/ ------------ -In each scheme directory, eight directories (``access_pattern``, ``quotas``, +In each scheme directory, nine directories (``access_pattern``, ``quotas``, ``watermarks``, ``core_filters``, ``ops_filters``, ``filters``, ``dests``, ``stats``, and ``tried_regions``) and three files (``action``, ``target_nid`` and ``apply_interval``) exist.
@@ -492,7 +492,7 @@ given DAMON-based operation scheme. Under the watermarks directory, five files (``metric``, ``interval_us``, ``high``, ``mid``, and ``low``) for setting the metric, the time interval between check of the metric, and the three watermarks exist. You can set and -get the five values by writing to the files, respectively. +get the five values by writing to and reading from the files, respectively. Keywords and meanings of those that can be written to the ``metric`` file are as below.
@@ -500,7 +500,7 @@ as below. - none: Ignore the watermarks - free_mem_rate: System's free memory rate (per thousand) -The ``interval`` should written in microseconds unit. +The ``interval_us`` should be written in microseconds unit. .. _sysfs_filters:
@@ -528,9 +528,9 @@ in the numeric order. Each filter directory contains nine files, namely ``type``, ``matching``, ``allow``, ``memcg_path``, ``addr_start``, ``addr_end``, ``min``, ``max`` -and ``target_idx``. To ``type`` file, you can write the type of the filter. -Refer to :ref:`the design doc <damon_design_damos_filters>` for available type -names, their meaning and on what layer those are handled. +and ``damon_target_idx``. To ``type`` file, you can write the type of the +filter. Refer to :ref:`the design doc <damon_design_damos_filters>` for +available type names, their meaning and on what layer those are handled. For ``memcg`` type, you can specify the memory cgroup of the interest by writing the path of the memory cgroup from the cgroups mount point to
@@ -540,7 +540,7 @@ files, respectively. For ``hugepage_size`` type, you can specify the minimum and maximum size of the range (closed interval) to ``min`` and ``max`` files, respectively. For ``target`` type, you can specify the index of the target between the list of the DAMON context's monitoring targets list to -``target_idx`` file. +``damon_target_idx`` file. You can write ``Y`` or ``N`` to ``matching`` file to specify whether the filter is for memory that matches the ``type``. You can write ``Y`` or ``N`` to
@@ -731,7 +731,7 @@ show results using tracepoint supporting tools like ``perf``. For example:: Each line of the perf script output represents each monitoring region. The first five fields are as usual other tracepoint outputs. The sixth field -(``target_id=X``) shows the ide of the monitoring target of the region. The +(``target_id=X``) shows the id of the monitoring target of the region. The seventh field (``nr_regions=X``) shows the total number of monitoring regions for the target. The eighth field (``X-Y:``) shows the start (``X``) and end (``Y``) addresses of the region in bytes. The ninth field (``X``) shows the
Signature · 1 line
2.47.3
Andrew Morton
maintainerQuoted 9 lines · On Tue, 19 May 2026 18:20:58 -0700 SeongJae Park <[email protected]> wrote:
Subject: [PATCH RESEND 0/3] mm/damon: reposting three reviewed patches
...
This series reposts patches that were reviewed by the DAMON maintainer but not yet added to mm-new, for more visibility. From their last posted versions, only minor changes including commit subject update,
Reviewed-by: and Acked-by: tags collection, and rebasing to latest mm-new were made by the DAMON maintainer.
fwiw, I don't think the Subject or the text are appropriate/useful for the long-term upstream kernel record. It's all short-term development-time info which is best kept below the "---" separator and discarded for the permanent record.
I rewrote the Subject: to "mm/damon: documentation and comment fixes" and left the [0/N] cover-leter empty.
SeongJae Park
maintainerQuoted 12 lines · On Thu, 21 May 2026 17:57:53 -0700 Andrew Morton <[email protected]>…
Quoted 9 lines · On Tue, 19 May 2026 18:20:58 -0700 SeongJae Park <[email protected]> wrote:
Subject: [PATCH RESEND 0/3] mm/damon: reposting three reviewed patches
...
This series reposts patches that were reviewed by the DAMON maintainer but not yet added to mm-new, for more visibility. From their last posted versions, only minor changes including commit subject update,
Reviewed-by: and Acked-by: tags collection, and rebasing to latest mm-new were made by the DAMON maintainer.
Quoted 4 lines
fwiw, I don't think the Subject or the text are appropriate/useful for the long-term upstream kernel record. It's all short-term development-time info which is best kept below the "---" separator and discarded for the permanent record.
I agree. I was also wondering what subject and commit message should be given here, because the original authors didn't meant to send these as one series. So I was assuming you may simply drop the cover letter and made this ridiculous one.
Quoted 3 lines
I rewrote the Subject: to "mm/damon: documentation and comment fixes" and left the [0/N] cover-leter empty.
This makes sense and seems better to me. I will do similar in future.
Thanks,
SJ