From: SJ Park <sj@kernel.org>
To: Aveline Noir <jm5905938@gmail.com>
Cc: SJ Park <sj@kernel.org>,
akpm@linux-foundation.org, damon@lists.linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] DAMON sysfs: failed update clears tried_regions snapshot
Date: Fri, 16 Oct 2026 07:01:06 -0700 [thread overview]
Message-ID: <20261016140106.118283-1-sj@kernel.org> (raw)
In-Reply-To: <CANOyQmHMRh6Sa=6N=hM8VzO0HRaFL0FxQB7An8=Y-X5GX36kmg@mail.gmail.com>
On Thu, 15 Oct 2026 19:12:25 -0700 Aveline Noir <jm5905938@gmail.com> wrote:
> Hi SJ,
>
> > Please do not "top-post" [1].
>
> Sorry about that. I'll avoid top-posting from now on : (
No worry, nobody knows everything from the beginning, and we all learn from
mistakes.
>
> > You shared 4 bug reports in very short time. Three of those are
> > from 32 bit.
> > Could you disclose the purpose of the testing and how you are
> > doing the testing, finding bugs, and reporting those?
>
> I've been trying to understand DAMON in more depth with help from
> an LLM, not deliberately hunting for bugs. It spotted a few possible
> problems as we went through the code. After checking the code and
> reproducing them in QEMU, I thought they were worth reporting.
That makes sense, thank you for sharing the context.
> If that wasn't the right way to go about it, please let me know :)
That's the right way. Nonetheless, disclosing this kind of information is very
helpful. Particularly nowadays, use of AI-like tools is nearly always better
to disclose. It is not because maintainers hate AI. It is because AI-like
tools are still something new that sometimes good but also do mistake, and
therefore maintainers are still learning the tools. I'd suggest disclosing
this kind of context in your future contexts, not only for DAMON, but for
kernel works in general.
>
> > Why would the tool tries to refresh the regions after the monitoring
> > is stopped?
>
> That's probably not something normal users would do. The test
> deliberately called the update after monitoring stopped and found
> that the failed request cleared the old snapshot. It looked
> unexpected, so I reported it to ask whether that's intended.
Makes sense. So I think this is not DAMON implementation problem. Tools
should aware this and do not try refreshing when the kdamond is terminated, or
remember old snapshot.
If this behavior is not documented, that's documentation issue that we shold
fix. Please feel free to send a patch for documenting, if you don't mind. If
DAMON user-space tool is not aware of this and give users unexpected results,
please feel free to send a PR for fixing it, if you don't mind.
>
> > Is this an answer to my bisection question?
>
> No, that wasn't a `git bisect` run. The suspect commit,
> `66178e4ec30a`, came from code review. I tested it and its
> parent `cce0b334c310` with the same setup. The parent kept
> the snapshot, but the newer commit cleared it.
Ok, that makes sense. Thank you for letting me know this. So, this is a
behavior that changed from that of the past. But I still feel the current
behavior is not a real problem. In a sense, if the kdamond is terminated, it
has no region and therefore showing no region makes sense to me. Please let me
know if I'm missing something or you have other opinions.
>
> Thx for your time, and sorry if I've caused any trouble:(
No worries. I'm also sorry if you felt you are suspected or not welcomed. I
believe now we are all good and you are welcomed. Thank you for kindly
answering all my questions.
Thanks,
SJ
[...]
prev parent reply other threads:[~2026-10-16 14:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 11:22 [BUG] DAMON sysfs: failed update clears tried_regions snapshot Aveline Noir
2026-10-15 14:05 ` SJ Park
2026-10-15 15:17 ` Aveline Noir
2026-10-16 1:26 ` SJ Park
2026-10-16 2:12 ` Aveline Noir
2026-10-16 14:01 ` 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=20261016140106.118283-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=jm5905938@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.