Re: [RFC PATCH 2/5] mm/damon/core: cap effective quota size to total monitored memory

[Ravi Jonnalagadda]

On Sun, May 17, 2026 at 11:37 AM SeongJae Park <sj@xxxxxxxxxx> wrote:
>
> Hello Ravi,
>
> On Sat, 16 May 2026 14:03:54 -0700 Ravi Jonnalagadda <ravis.opensrc@xxxxxxxxx> wrote:
>
> > The DAMOS quota goal tuner can compute an effective size (esz) larger
> > than the total monitored memory because it integrates over cumulative
> > deltas without bounding by the actual workload size.  Once esz exceeds
> > total monitored memory, the per-tick "remaining quota" arithmetic
> > stops being meaningful: any scheme can apply to the entire monitored
> > space and "remaining" stays positive indefinitely.
>
> Nice finding!
>
> >
> > Cap esz to the total size of all currently monitored regions as a
> > final bound after all other quota calculations.  Add
> > damon_ctx_total_monitored_sz() helper that sums region sizes across
> > all targets.
>
> You could also make an arbitrary cap by setting the static size quota.  That
> is, if there are not only quota goal but also the size quota and/or time quota,
> and the different types of quotas disagree about the real quota, DAMOS uses
> smallest quota.  You could read damos_set_effective_quota() code and kernel-doc
> comment of 'struct damos_quota' for more details.
>
> So you could apply the total monitoring region size cap by setting the size
> quota of the total monitoring region size.  Could that work for you?
>
> Adding the total monitoring region size cap makes sense to me, and I think that
> will make user experience better.  But, if the size quota based cap works, that
> could also be handled on user space in an easier and even a betetr way.  If so,
> I'd prefer the direction, to reduce kernel code complexity.  What do you think?

Hello SJ,

Agreed.  quota->sz combined with the smallest-quota-wins rule in
damos_set_effective_quota does express this cap from userspace
without kernel changes, and keeping the kernel side clean is the
right call.

If the UX argument carries weight later, I'm happy to respin v2
with sashiko fixes addressed.

Thanks,
Ravi

>
>
> Thanks,
> SJ
>
> [...]