From: Yueyang Pan <pyyjason@gmail.com>
To: David Hildenbrand <david@redhat.com>
Cc: SeongJae Park <sj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Usama Arif <usamaarif642@gmail.com>,
damon@lists.linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] mm/damon: Add damos_stat support for vaddr
Date: Wed, 30 Jul 2025 15:24:36 -0700 [thread overview]
Message-ID: <aIqbpFsoqbt77j8f@devbig569.cln6.facebook.com> (raw)
In-Reply-To: <0cb3d5a5-683b-4dba-90a8-b45ab83eec53@redhat.com>
On Tue, Jul 29, 2025 at 04:11:32PM +0200, David Hildenbrand wrote:
> On 29.07.25 15:53, Yueyang Pan wrote:
> > From: PanJason <pyyjason@gmail.com>
> >
> > This patch adds support for damos_stat in virtual address space.
> > It leverages the walk_page_range to walk the page table and gets
> > the folio from page table. The last folio scanned is stored in
> > damos->last_applied to prevent double counting.
> > ---
> > mm/damon/vaddr.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 112 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> > index 87e825349bdf..3e319b51cfd4 100644
> > --- a/mm/damon/vaddr.c
> > +++ b/mm/damon/vaddr.c
> > @@ -890,6 +890,117 @@ static unsigned long damos_va_migrate(struct damon_target *target,
> > return applied * PAGE_SIZE;
> > }
> > +struct damos_va_stat_private {
> > + struct damos *scheme;
> > + unsigned long *sz_filter_passed;
> > +};
> > +
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > +static int damos_va_stat_pmd_entry(pmd_t *pmd, unsigned long addr,
> > + unsigned long next, struct mm_walk *walk)
> > +{
> > + struct damos_va_stat_private *priv = walk->private;
> > + struct damos *s = priv->scheme;
> > + unsigned long *sz_filter_passed = priv->sz_filter_passed;
> > + struct folio *folio;
> > + spinlock_t *ptl;
> > + pmd_t pmde;
> > +
> > + ptl = pmd_lock(walk->mm, pmd);
> > + pmde = pmdp_get(pmd);
> > +
> > + if (!pmd_present(pmde) || !pmd_trans_huge(pmde))
> > + goto unlock;
> > +
> > + /* Tell page walk code to not split the PMD */
> > + walk->action = ACTION_CONTINUE;
> > +
> > + folio = damon_get_folio(pmd_pfn(pmde));
> > + if (!folio)
> > + goto unlock;
> > +
> > + if (damon_invalid_damos_folio(folio, s))
> > + goto update_last_applied;
> > +
> > + if (!damos_va_filter_out(s, folio, walk->vma, addr, NULL, pmd)){
> > + *sz_filter_passed += folio_size(folio);
>
> See my comment below regarding vm_normal_page and folio references.
>
> But this split into two handlers is fairly odd. Usually we only have a
> pmd_entry callback (see madvise_cold_or_pageout_pte_range as an example),
> and handle !CONFIG_TRANSPARENT_HUGEPAGE in there.
>
> Then, there is also no need to mess with ACTION_CONTINUE
>
Hi David. Thanks for your comment. I was not aware of the convention so I
followed the existing code. I had a discussion with SJ today and in the
next version I will change this by combining *pmd_entry() and *pte_entry().
We will also format the existing code in future patches.
> > + }
> > +
> > + folio_put(folio);
> > +update_last_applied:
> > + s->last_applied = folio;
> > +unlock:
> > + spin_unlock(ptl);
> > + return 0;
> > +}
> > +#else
> > +#define damon_va_stat_pmd_entry NULL
> > +#endif
> > +
> > +static int damos_va_stat_pte_entry(pte_t *pte, unsigned long addr,
> > + unsigned long next, struct mm_walk *walk)
> > +{
> > + struct damos_va_stat_private *priv = walk->private;
> > + struct damos *s = priv->scheme;
> > + unsigned long *sz_filter_passed = priv->sz_filter_passed;
> > + struct folio *folio;
> > + pte_t ptent;
> > +
> > + ptent = ptep_get(pte);
> > + if (pte_none(ptent) || !pte_present(ptent))
> > + return 0;
> > +
> > + folio = damon_get_folio(pte_pfn(ptent));
> > + if (!folio)
> > + return 0;
>
> We have vm_normal_folio() and friends for a reason -- so you don't have to
> do pte_pfn() manually.
>
> ... and now I am confused. We are holding the PTL, so why would you have to
> grab+put a folio reference here *at all*.
>
Thanks for pointing out. I thought someone could still change the folio and
realized it could not happen with PTL. I will use vm_normal_folio* in the
next version.
> --
> Cheers,
>
> David / dhildenb
>
next prev parent reply other threads:[~2025-07-30 22:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 13:53 [PATCH v1 0/2] mm/damon: Add damos_stat support for vaddr Yueyang Pan
2025-07-29 13:53 ` [PATCH v1 1/2] mm/damon: Move invalid folio and has filter to ops-common Yueyang Pan
2025-07-29 18:20 ` SeongJae Park
2025-07-29 13:53 ` [PATCH v1 2/2] mm/damon: Add damos_stat support for vaddr Yueyang Pan
2025-07-29 14:11 ` David Hildenbrand
2025-07-29 17:46 ` SeongJae Park
2025-07-30 22:24 ` Yueyang Pan [this message]
2025-07-29 18:15 ` SeongJae Park
2025-07-29 18:21 ` SeongJae Park
2025-07-29 18:34 ` [PATCH v1 0/2] " SeongJae 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=aIqbpFsoqbt77j8f@devbig569.cln6.facebook.com \
--to=pyyjason@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sj@kernel.org \
--cc=usamaarif642@gmail.com \
/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.