Re: [RFC PATCH 3/5] mm/damon/core: floor effective quota size at minimum region size

[Ravi Jonnalagadda]

On Sun, May 17, 2026 at 11:47 AM SeongJae Park <sj@xxxxxxxxxx> wrote:
>
> On Sat, 16 May 2026 14:03:55 -0700 Ravi Jonnalagadda <ravis.opensrc@xxxxxxxxx> wrote:
>
> > The CONSIST quota goal tuner initializes esz_bp to 0, producing an
> > effective quota size (esz) of 1 byte on the first tick.
> > damos_quota_is_full() rejects all regions when esz < min_region_sz
> > (default PAGE_SIZE = 4096), so no regions can be tried and no
> > feedback reaches the tuner — a bootstrapping deadlock.
>
> That depend on whether the goal is already [over]-achieved.  If the goal is
> achieved, the tuner will think no change is needed, so keep the
> effectively-zero quota.  If the goal is over-achived, the tuner will think the
> DAMOS scheme should be less aggressive, but it is already effectively-zero
> quota, so keep having effectively-zero quota.
>
> If the ogal is under-achived, the logic will iteratively increase the internal
> esz (esz_bp), until it exceeds the min_region_sz, and finally start making some
> effects.
>
> So, unless the goal is already [over]-achieved, there is no deadlock.  If the
> goal is already [over]-achieved, why we would want to make DAMOS do something?
>
> Am I missing something?
>

Hello SJ,

You're not missing anything; you're right.  Stock DAMON's
feed-loop tuner ramps esz_bp out of the seed quickly under an
under-achieved goal -- on the order of ten-some ticks at the
1000ms reset_interval the in-tree DAMON modules use, so the
floor isn't gating anything that wouldn't bootstrap on its own.
No deadlock.

I owe a clearer accounting of where this patch and patch 1 came
from, since the same origin story applies to both.  Both came
from a parallel debug effort and should not have been carried
into this set.

The work that produced this series came out of an effort to
enable hardware-sampled hotness as a DAMON access source -- the
companion AMD IBS RFC

  https://lore.kernel.org/linux-mm/20260516223439.4033-1-ravis.opensrc@xxxxxxxxx/

-- and to characterise its closed-loop convergence with the
existing CONSIST tuner on a heterogeneous DRAM+CXL setup.  Early
in that effort I was hitting random NMI-context hangs on the per-CPU
report path that prevented runs from completing, and while
debugging those hangs I wasn't sure which direction the
convergence anomalies were coming from -- the sampling backend,
the report-ring path, the tuner shape, or the quota controller.

I made two controller-side experiments as scaffolding while I
narrowed the problem down:

  - A per-tick growth cap on the goal-feedback tuner
    ("max_delta_bp" at 5%/tick) to slow how fast esz could grow
    on a transient.  That cap stretches the bootstrap above
    from ~13s to several minutes, so I added a floor at
    min_region_sz to short-cut the bootstrap.  That landed here
    as patch 3.

  - A separate access-rate seeding helper (clear-on-migration)
    for the goal-feedback loop.  Some early versions of that
    helper left the access-rate fields in inconsistent states
    and damon_moving_sum() landed in an underflow path I hadn't
    seen before.  I added a saturating-subtract guard to that
    function.  That landed here as patch 1.

Once cpuhp-related fixes on the per-CPU sampling path landed
and the NMI stability problem was actually resolved, the
convergence anomalies were tracked down to the sampling/ring
side, not the controller side.  I dropped the max_delta_bp knob
and fixed the seeding helper to maintain its invariants.
Patches 1 and 3 were carried into this set even though their
justifications had gone away:

  - Patch 1: with the seeding helper fixed, stock callers don't
    reach the underflow path -- the invariant holds at every
    aggregation boundary in stock DAMON, as you noted.  Belongs
    with the seeding helper if and when that work goes upstream.

  - Patch 3 (this one): with max_delta_bp dropped, the slow
    bootstrap doesn't happen -- the ~13s ramp is fast enough
    that there's no problem to solve.  Once stability was
    sorted I also moved the closed-loop runs in the companion
    RFC to the temporal tuner, where the bootstrap concern
    this patch addresses doesn't even arise (esz_bp saturates
    to ULONG_MAX immediately when score=0).

Apologies;both should have come out when
max_delta_bp and the seeding helper did.

Dropping patches 1 and 3.

Patches 2, 4, and 5 are independent of this scaffolding; I'll
reply on each thread separately with the relevant context.

Thanks again for the careful review.

Best,
Ravi

> I'd like to discuss this high level thing first, before digging deep into the
> details.
>
>
> Thanks,
> SJ
>
> [...]