A PSI quota goal without a previous sample is scored as achieved. This
leaves the consist tuner's input unchanged but sets the temporal quota
to zero. Preserve the temporal tuner's previous goal-achievement state
using its effective quota, as SJ suggested [1], and test the helper with
explicit PSI totals.

All 42 DAMON KUnit tests pass on x86-64 and i386. With the original
scoring retained in the extracted helper, the new test fails on both.
In a live damo test, a goals-only update changes a running 64 KiB quota
to zero for an unmeasured round without the fix. With the fix, the
effective quota stays at 64 KiB. A full damo tune also needs the separate
quota-reset fix [3], so the context update preserves the running quota
used for this decision.

DAMON selftests show no new failures (QEMU TCG guest; the wss_estimation
test misses its accuracy bounds with and without the fix).

Changes since v1 [2]:
 - Use the previous effective quota for the temporal decision, including
   when it is zero. Keep resetting last_psi_total for new and updated
   goals.
 - Move the current-value calculation and last_psi_total update into a
   helper. Test both tuners with explicit samples and check
   last_psi_total after each call.

The series is based on mm-new as of September 20.

[1] https://lore.kernel.org/damon/20260916001311.101024-1-sj@kernel.org/
[2] https://lore.kernel.org/20260915060937.3423-1-kmehltretter@gmail.com/
[3] https://lore.kernel.org/20260921003047.12041-1-kmehltretter@gmail.com/

Karl Mehltretter (2):
  mm/damon/core: keep the temporal tuner quota over an unmeasured PSI
    round
  mm/damon/tests/core-kunit: test PSI goal values with explicit samples

 mm/damon/core.c             | 30 ++++++++++++++++++++------
 mm/damon/tests/core-kunit.h | 43 +++++++++++++++++++++++++++++++++++++
 2 files changed, 66 insertions(+), 7 deletions(-)


base-commit: 185111f116aabf202d12ce440c0f6e9bae073514
-- 
2.53.0

On Mon, 21 Sep 2026 04:00:11 +0200 Karl Mehltretter <kmehltretter@gmail.com> wrote:

> A PSI quota goal without a previous sample is scored as achieved. This
> leaves the consist tuner's input unchanged but sets the temporal quota
> to zero. Preserve the temporal tuner's previous goal-achievement state
> using its effective quota, as SJ suggested [1], and test the helper with
> explicit PSI totals.
> 
> All 42 DAMON KUnit tests pass on x86-64 and i386. With the original
> scoring retained in the extracted helper, the new test fails on both.
> In a live damo test, a goals-only update changes a running 64 KiB quota
> to zero for an unmeasured round without the fix. With the fix, the
> effective quota stays at 64 KiB. A full damo tune also needs the separate
> quota-reset fix [3], so the context update preserves the running quota
> used for this decision.
> 
> DAMON selftests show no new failures (QEMU TCG guest; the wss_estimation
> test misses its accuracy bounds with and without the fix).
> 
> Changes since v1 [2]:
>  - Use the previous effective quota for the temporal decision, including
>    when it is zero. Keep resetting last_psi_total for new and updated
>    goals.
>  - Move the current-value calculation and last_psi_total update into a
>    helper. Test both tuners with explicit samples and check
>    last_psi_total after each call.
> 
> The series is based on mm-new as of September 20.
> 
> [1] https://lore.kernel.org/damon/20260916001311.101024-1-sj@kernel.org/
> [2] https://lore.kernel.org/20260915060937.3423-1-kmehltretter@gmail.com/
> [3] https://lore.kernel.org/20260921003047.12041-1-kmehltretter@gmail.com/

The patch 1 has wrong Fixes: tag, as I replied to it with two options to path
forward.  Speculatively assuming your preferrence is option 2 (adding this
series with fixed 'Fixes:' tag), I applied this series to damon/next [1] tree
with the suggested Fixes: tag modification.  Let me know if you want the
options 1 (squash it into the incomplete fix [2] before it is merged into the
mainline).

Unless you want option 1, and if this series is not added to mm.git in short
term (~1 week?) with option 1 update, I will ask mm.git maintainer (Andrew
Morton) to pick this.  So, no action from your side is needed for now unless
you want option 1.  If it seems I forgot doing that or you cannot wait for my
action, please feel free to ping me or Andrew.

[1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees
[2] commit b73198a47ffe ("mm/damon/core: handle uninitialized damos_quota_goal->last_psi_total")


Thanks,
SJ

[...]

On Mon, Sep 21, 2026 at 09:47:48AM +0100, SJ Park wrote:
> The patch 1 has wrong Fixes: tag, as I replied to it with two options to path
> forward.  Speculatively assuming your preferrence is option 2 (adding this
> series with fixed 'Fixes:' tag), I applied this series to damon/next [1] tree
> with the suggested Fixes: tag modification.  Let me know if you want the
> options 1 (squash it into the incomplete fix [2] before it is merged into the
> mainline).
> 
> Unless you want option 1, and if this series is not added to mm.git in short
> term (~1 week?) with option 1 update, I will ask mm.git maintainer (Andrew
> Morton) to pick this.  So, no action from your side is needed for now unless
> you want option 1.  If it seems I forgot doing that or you cannot wait for my
> action, please feel free to ping me or Andrew.
> 

Hello SJ,

Thanks for reviewing both patches!

I used b73198a47ffe in Fixes because that commit introduced the problem
with the temporal tuner.

I thought a Fixes tag could also point to a commit that is still in a
maintainer tree. The tip handbook describes that for tip [1], though mm
may handle it differently.

The hash can still change in mm-unstable, so the tag may need updating.

I also found this reply from Andrew [2]. He says he tracks these fixes
by filename and folds them into the original patch before moving it to
non-rebasing git.

Maybe squashing is indeed simpler here, also for backports.

So either option is fine with me. I'll leave that to you and Andrew.

[1] https://docs.kernel.org/process/maintainer-tip.html#ordering-of-commit-tags
[2] https://lore.kernel.org/r/20260313091738.354244f6fb500bef3bad1fa1@linux-foundation.org/

Thanks,
Karl

On Mon, 21 Sep 2026 20:39:27 +0200 Karl Mehltretter <kmehltretter@gmail.com> wrote:

> On Mon, Sep 21, 2026 at 09:47:48AM +0100, SJ Park wrote:
> > The patch 1 has wrong Fixes: tag, as I replied to it with two options to path
> > forward.  Speculatively assuming your preferrence is option 2 (adding this
> > series with fixed 'Fixes:' tag), I applied this series to damon/next [1] tree
> > with the suggested Fixes: tag modification.  Let me know if you want the
> > options 1 (squash it into the incomplete fix [2] before it is merged into the
> > mainline).
> > 
> > Unless you want option 1, and if this series is not added to mm.git in short
> > term (~1 week?) with option 1 update, I will ask mm.git maintainer (Andrew
> > Morton) to pick this.  So, no action from your side is needed for now unless
> > you want option 1.  If it seems I forgot doing that or you cannot wait for my
> > action, please feel free to ping me or Andrew.
> > 
> 
> Hello SJ,
> 
> Thanks for reviewing both patches!
> 
> I used b73198a47ffe in Fixes because that commit introduced the problem
> with the temporal tuner.
> 
> I thought a Fixes tag could also point to a commit that is still in a
> maintainer tree. The tip handbook describes that for tip [1], though mm
> may handle it differently.

You could do use a commit hash that is still in a maintainer tree.  I also
sometimes do so.  But in the case it is better to explicitly mention it is for
squashing on mm-unstable.  And if it was the intention, in this patch series,
you were better to split the kunit patch.

> 
> The hash can still change in mm-unstable, so the tag may need updating.
> 
> I also found this reply from Andrew [2]. He says he tracks these fixes
> by filename and folds them into the original patch before moving it to
> non-rebasing git.
> 
> Maybe squashing is indeed simpler here, also for backports.
> 
> So either option is fine with me. I'll leave that to you and Andrew.

Thank you for clarifying, Karl.  I was initially tempted to keep what I did
(option 2), but maybe that's only because I am too lazy.  Let's do squash.
Unless others raise other opinion, I will repost patch 1 with updated commit
message tomorrow.

I will keep patch 2 in damon/next and repost for mm.git merge as I explained in
the earlier reply.


Thanks,
SJ

[...]