From: SJ Park <sj@kernel.org>
To: SJ Park <sj@kernel.org>
Cc: sashiko-bot@kernel.org, "Krishna Iyer" <kiyer@crusoe.ai>,
damon@lists.linux.dev
Subject: Re: [PATCH 2/6] mm/damon/ops-common: handle hugetlb folios in folio mkold/young rmap walkers
Date: Sun, 30 Aug 2026 11:10:33 -0700 [thread overview]
Message-ID: <20260830181034.103943-1-sj@kernel.org> (raw)
In-Reply-To: <20260830161325.99195-1-sj@kernel.org>
On Sun, 30 Aug 2026 09:13:33 -0700 SJ Park <sj@kernel.org> wrote:
> On Sun, 30 Aug 2026 05:28:55 +0000 sashiko-bot@kernel.org wrote:
[...]
> > [Severity: Medium]
> > Will mmu_notifier_test_young() miss accesses within shattered huge pages here?
> >
> > Since the kernel's mmu_notifier_test_young() API does not take a size
> > parameter, passing only the base address of the huge page means it will
> > only evaluate the first base page.
> >
> > For secondary MMUs like KVM EPT that map huge pages as multiple smaller
> > pages, wouldn't accesses to other subpages within the huge page be completely
> > missed? This could cause DAMON to classify the huge page as colder than it
> > actually is, which might lead to inappropriate reclaim or migration decisions.
>
> This is also a pre-existing issue. I will work on fixing this.
Actually, the curernt implementation is correct. The goal here is to know if
the single byte of the address is accessed. It works in page granularity for
most cases due to limitations. That's not the intention. So I think this can
just be as-is.
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-08-30 18:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 5:14 [PATCH 0/6] mm/damon: support access monitoring of hugetlb-backed memory Krishna Iyer
2026-08-30 5:14 ` [PATCH 1/6] mm/damon: move damon_hugetlb_mkold() from vaddr to ops-common Krishna Iyer
2026-08-30 5:26 ` sashiko-bot
2026-08-30 16:33 ` SJ Park
2026-08-30 5:14 ` [PATCH 2/6] mm/damon/ops-common: handle hugetlb folios in folio mkold/young rmap walkers Krishna Iyer
2026-08-30 5:28 ` sashiko-bot
2026-08-30 16:13 ` SJ Park
2026-08-30 18:10 ` SJ Park [this message]
2026-08-30 16:48 ` SJ Park
2026-08-30 5:14 ` [PATCH 3/6] mm/damon/paddr: support hugetlb folios in access monitoring Krishna Iyer
2026-08-30 5:29 ` sashiko-bot
2026-08-30 16:15 ` SJ Park
2026-08-30 17:12 ` SJ Park
2026-08-30 5:14 ` [PATCH 4/6] mm/damon: support flush-assisted access bit clearing for monitoring Krishna Iyer
2026-08-30 5:23 ` sashiko-bot
2026-08-30 5:14 ` [PATCH 5/6] mm/damon/sysfs: support aging_flush Krishna Iyer
2026-08-30 5:22 ` sashiko-bot
2026-08-30 5:14 ` [PATCH 6/6] mm/damon/stat: " Krishna Iyer
2026-08-30 5:18 ` sashiko-bot
2026-08-30 18:04 ` [PATCH 0/6] mm/damon: support access monitoring of hugetlb-backed memory SJ Park
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=20260830181034.103943-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=damon@lists.linux.dev \
--cc=kiyer@crusoe.ai \
--cc=sashiko-bot@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