mm/damon/core: trace esz at first setup
Subsystems (3)
SeongJae Park
maintainerRFC PATCH 1/1 mm/damon/core: trace esz at first setup
DAMON traces effective size quota from the second update, only if a change has been made by the update. Tracing only changed updates was an intentional decision to avoid unnecessary same value tracing. Always skipping the first value is just an unintended mistake.
The mistake makes the tracepoint based investigation incomplete, because the first effective size quota is never traced. It is not a big issue when the 'consist' quota tuner is used, because it keeps changing the quota in the usual setup.
However, when the 'temporal' tuner is used, the quota value is not changed before the goal achievement status is completely changed. For example, if the DAMOS scheme is started with an under-achieved goal, the quota is set to the maximum value, and kept the same value until the goal is achieved. Because DAMON skips the first value, the user cannot know what effective quota the current scheme is using. Only after the goal is achieved, the effective quota is changed to zero, and traced.
Unconditionally trace the initial quota value to fix this problem.
Note that the 'temporal' quota tuner was introduced by commit af738a6a00c1 ("mm/damon/core: introduce DAMOS_QUOTA_GOAL_TUNER_TEMPORAL"), which was added to 7.1-rc1. But even with the 'consist' quota tuner, the tracing is unintentionally incomplete. Hence this commit marks the introduction of the trace event as the broken commit.
--- mm/damon/core.c | 2 ++ 1 file changed, 2 insertions(+)
mm/damon/core.c +2 -0
@@ -2886,6 +2886,8 @@ static void damos_adjust_quota(struct damon_ctx *c, struct damos *s)if (!quota->total_charged_sz && !quota->charged_from) { quota->charged_from = jiffies;damos_set_effective_quota (c, s); +if (trace_damos_esz_enabled ()) +damos_trace_esz (c, s, quota); }/* New charge window starts */
base-commit: abe8c076ff4a1283d77c1c5cb7b975723314aec9
Signature · 1 line
2.47.3
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The monotonic accumulators total_charged_ns and total_charged_sz will rapidly overflow on 32-bit architectures, breaking the throughput estimation logic. --
commit 4cb83c3ed801305fa15e94548668201c275a1037
Author: SeongJae Park <[email protected]>
mm/damon/core: trace esz at first setup
This commit fixes an issue where the initial effective size quota is not traced, which leaves tracepoint investigations incomplete when using the temporal tuner. It updates the quota adjustment logic to unconditionally trace the initial quota value.
mm/damon/core.c static void damos_adjust_quota(struct damon_ctx *c, struct damos *s) · line 2883
Quoted 6 lines
mm/damon/core.c +0
-0@@ -2883,6 +2883,8 @@ static void damos_adjust_quota(struct damon_ctx *c, struct damos *s)if (!quota->total_charged_sz && !quota->charged_from) {
[Severity: High]
This isn't a bug introduced by this patch, but will total_charged_ns and total_charged_sz overflow on 32-bit architectures?
Since unsigned long is 32 bits on those systems, total_charged_ns will overflow after roughly 4.29 seconds of total active execution time.
Additionally, the throughput calculation in damos_set_effective_quota():
damos_set_effective_quota() {
...
if (quota->total_charged_ns)
throughput = mult_frac(quota->total_charged_sz,
1000000, quota->total_charged_ns);
...
}uses mult_frac() which evaluates (x % d) * n internally using the type of x. Since the remainder could be up to total_charged_ns - 1, multiplying it by 1,000,000 will quickly overflow the 32-bit boundary. This produces incorrect throughput estimates and impacts the effective size quota calculations on 32-bit systems.
Quoted 7 lines
mm/damon/core.c +2
-0quota->charged_from = jiffies;damos_set_effective_quota (c, s); +if (trace_damos_esz_enabled ()) +damos_trace_esz (c, s, quota); }/* New charge window starts */
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
SeongJae Park
maintainerQuoted 4 lines · On Wed, 20 May 2026 01:18:37 +0000 [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The monotonic accumulatorstotal_charged_nsandtotal_charged_szwill rapidly overflow on 32-bit architectures, breaking the throughput estimation logic.
Not introduced by this patch, so no blocker.
Quoted 36 lines
--
commit
4cb83c3ed801305fa15e94548668201c275a1037
Author: SeongJae Park <[email protected]>
mm/damon/core: trace esz at first setupThis commit fixes an issue where the initial effective size quota is not traced, which leaves tracepoint investigations incomplete when using the temporal tuner. It updates the quota adjustment logic to unconditionally trace the initial quota value.
mm/damon/core.c static void damos_adjust_quota(struct damon_ctx *c, struct damos *s) · line 2883
Quoted 6 lines
mm/damon/core.c +0
-0@@ -2883,6 +2883,8 @@ static void damos_adjust_quota(struct damon_ctx *c, struct damos *s)if (!quota->total_charged_sz && !quota->charged_from) {[Severity: High]
This isn't a bug introduced by this patch, but willtotal_charged_nsandtotal_charged_szoverflow on 32-bit architectures?Since unsigned long is 32 bits on those systems,
total_charged_nswill overflow after roughly 4.29 seconds of total active execution time.Additionally, the throughput calculation in
damos_set_effective_quota():damos_set_effective_quota() { ... if (quota->total_charged_ns) throughput = mult_frac(quota->total_charged_sz, 1000000, quota->total_charged_ns); ... }
Quoted 5 lines
uses
mult_frac()which evaluates (x % d) * n internally using the type of x. Since the remainder could be up tototal_charged_ns- 1, multiplying it by 1,000,000 will quickly overflow the 32-bit boundary. This produces incorrect throughput estimates and impacts the effective size quota calculations on 32-bit systems.
On 32-bit environment, addr_unit can be used to workaround this issue. On systems that runs DAMON after a reasonable amount of tests, the issue should not happen. I'm thinking about a better solution, though.
Anyway, not a blocker of this patch.
Thanks,
SJ
[...]