DAMON development mailing list
 help / color / mirror / Atom feed
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

[...]

  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