From: "Kunwu Chan" <kunwu.chan@linux.dev>
To: "SeongJae Park" <sj@kernel.org>
Cc: "SeongJae Park" <sj@kernel.org>,
"Kunwu Chan" <chentao@kylinos.cn>,
"Wang Lian" <lianux.mm@gmail.com>,
akpm@linux-foundation.org, damon@lists.linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/damon: fix stale TLB young-state handling on arm64
Date: Sun, 31 May 2026 12:16:49 +0000 [thread overview]
Message-ID: <cfa837d8641972b79a404f4f9d489644dd6675f7@linux.dev> (raw)
In-Reply-To: <20260526145034.91594-1-sj@kernel.org>
Hi SJ,
[...]
> Thank you for clarifying!
>
> wss_estimation increases its working set size up to 160 MiB for this issue.
> Seems your test machine has large TLB buffer. I think we should decide the
> limit based on the real running system configuration and apply similar approach
> to other tests including the apply_interval.
>
> For out-of-tree tests, we may better to provide a guideline, too. E.g., run
> this sort of test program with this DAMON config to find the reliable test
> working set size on your setup.
>
Thanks for the detailed analysis.
We agree that improving the documentation and aligning the tests is a
better direction for now. Adding an optional feature mainly for testing
could confuse users and create additional maintenance burden.
We've already done some selftests:
https://lore.kernel.org/damon/20260531085633.48626-1-kunwu.chan@linux.dev/
[...]
> >
> I was thinking this again. I still want DAMON to be easy to test. But, is
> this making tests that difficult? Users could increase the test working set
> size. I'm not very sure that is too diifficult to add new optional feature.
> Meanwhille, adding an optional feature for only test might make users be
> confused. DAMON usage might also be diverged and add maintenance burdens.
>
> So, now I think another option is improving the documentation. It shouldd
> clearly explain how and why DAMON does not flush TLB and what is the expected
> problems (in tests) and recommendation. In this option, we should also update
> existing DAMON tests to be reliable and aligned with the documented
> recommendation. If we find it becomes a problem on testing even after applying
> the recommendation, or on production, we can revisit.
>
> Regardless of the decision about the optional feature in DAMON, I think such
> documentation and tests improvement should be made.
>
> Maybe I'm biased, so any input would be appreicatedd. What do you think, Kunwu
> and Lian?
>
We think that makes sense. Explaining the rationale for not flushing TLB,
the limitations this can introduce for tests, and recommendations for
choosing reliable test working set sizes would be helpful.
If we later find cases where the documented recommendations are still
insufficient, we can revisit more intrusive approaches.
I'd be happy to help with the documentation work if needed. Please let
me know if you'd like me to prepare a draft patch.
Thanks,
Kunwu
> Thanks,
> SJ
>
> [...]
>
next prev parent reply other threads:[~2026-05-31 12:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 14:48 [PATCH] mm/damon: fix stale TLB young-state handling on arm64 Kunwu Chan
2026-05-25 17:46 ` SeongJae Park
2026-05-26 8:57 ` Kunwu Chan
2026-05-26 14:50 ` SeongJae Park
2026-05-31 12:16 ` Kunwu Chan [this message]
2026-05-31 16:24 ` SeongJae Park
2026-06-01 2:09 ` Kunwu Chan
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=cfa837d8641972b79a404f4f9d489644dd6675f7@linux.dev \
--to=kunwu.chan@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=chentao@kylinos.cn \
--cc=damon@lists.linux.dev \
--cc=lianux.mm@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sj@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