Re: [PATCH v2 0/2] mm/damon: preserve temporal quota state for unmeasured PSI goals

[SJ Park <sj@kernel.org>]

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

[...]