Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: SJ Park <sj@kernel.org>
To: Liew Rui Yan <aethernet65535@gmail.com>
Cc: SJ Park <sj@kernel.org>,
	akpm@linux-foundation.org, damon@lists.linux.dev,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v2.1] mm/damon/core: fix false positive in damos_quota_is_full() when esz is zero
Date: Sat,  5 Sep 2026 09:12:33 -0700	[thread overview]
Message-ID: <20260905161233.81892-1-sj@kernel.org> (raw)
In-Reply-To: <20260905103935.4871-1-aethernet65535@gmail.com>

On Sat,  5 Sep 2026 18:36:58 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> On Fri, 04 Sep 2026 17:25:34 -0700 SJ Park <sj@kernel.org> wrote:
> 
> > On Fri,  4 Sep 2026 23:35:38 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
> > 
> > > That said, it's not important for me to add explanations to the
> > > document, but may I know why commit [2] changed the behavior which
> > > introduced by commit [1]?
> > > 
> > > Commit [1] Behavior:
> > > 
> > >     if (quota->esz && quota->changed_sz >= quota->esz)
> > >         s->stat.qt_exceeds++;
> > > 
> > > Commit [2] Behavior:
> > > 
> > >     if (damos_quota_is_full(quota, c->min_region_sz))
> > >         s->stat.qt_exceeds++;
> > > 
> > > Before commit [2], qt_exceeds will only increase when quota->esz is not
> > > zero, but after commit [2], qt_exceeds also increase even when
> > > quota->esz is zero.  I'd love to understand the rationale behind this
> > > change to better grasp the design evolution.
> > > 
> > > [1] 6268eac34ca30 ("mm/damon/schemes: account how many times quota limit has exceeded")
> > >     (Fri Jan 14 14:10:20 2022 -0800)
> > > [2] c7ec7d5f6b3d1 ("mm/damon/core: handle <min_region_sz remaining quota as empty")
> > >     (Mon Apr 27 18:33:50 2026 -0700)
> > 
> > Seems commit c7ec7d5f6b3d1 didn't make a behavior change that you are
> > describing.
> 
> I actually wanted to point out the behavior difference between commit [1]
> and [2], but I've understood and agreed with your point.
> 
> > 
> > '''
> > $ git show c7ec7d5f6b3d1
> > [...]
> > @@ -2601,8 +2613,7 @@ static void damos_adjust_quota(struct damon_ctx *c, struct damos *s)
> >         if (!time_in_range_open(jiffies, quota->charged_from,
> >                                 quota->charged_from +
> >                                 msecs_to_jiffies(quota->reset_interval))) {
> > -               if (damos_quota_is_set(quota) &&
> > -                               quota->charged_sz >= quota->esz)
> > +               if (damos_quota_is_full(quota, c->min_region_sz))
> >                         s->stat.qt_exceeds++;
> >                 quota->total_charged_sz += quota->charged_sz;
> >                 quota->charged_from = jiffies;
> > '''
> > 
> > And I don't think there was a behavior change.  Hopefully commit 54419bbd0ee3
> > ("mm/damon/core: allow quota goals set zero effective size quota") will give
> > you some clues.
> 
> Thank you very much for your clarifying :>
> 
> Now I completely understand why there is different behavior

I told you I don't think there was a behavior change.  I still think so.

> between
> commit [1] and [2].  Because in commit [1], esz==0 only means quota is
> unlimited.

No.  Commit 54419bbd0ee3 says "DAMON core assumes zero effective quota means
the user has set no quota."


> After commit 54419bbd0ee3, esz==0 also can means do not have
> quota at all.

That's what the commit is describing the before-commit status...

> But the qt_exceeds should just not increase when quota is
> unlimited, that's why the current implementation is completely correct.

There is no unlimited quota.  Hence I don't understand what you are saying
here.  Please carefully read the commit message again.

> 
> Best regards,
> Rui Yan


Thanks,
SJ


      reply	other threads:[~2026-09-05 16:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02  8:44 [PATCH v2.1] mm/damon/core: fix false positive in damos_quota_is_full() when esz is zero Liew Rui Yan
2026-09-02 14:10 ` SJ Park
2026-09-02 14:22   ` Liew Rui Yan
2026-09-02 14:48     ` SJ Park
2026-09-02 22:31       ` Liew Rui Yan
2026-09-03  0:33         ` SJ Park
2026-09-03 12:41           ` Liew Rui Yan
2026-09-03 14:05             ` SJ Park
2026-09-04  8:07               ` Liew Rui Yan
2026-09-04 14:05                 ` SJ Park
2026-09-04 15:35                   ` Liew Rui Yan
2026-09-05  0:25                     ` SJ Park
2026-09-05 10:36                       ` Liew Rui Yan
2026-09-05 16:12                         ` SJ Park [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260905161233.81892-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=aethernet65535@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox