From: SJ Park <sj@kernel.org>
To: Lian Wang <lianux.mm@gmail.com>
Cc: SJ Park <sj@kernel.org>,
damon@lists.linux.dev, linux-mm@kvack.org,
daichaobing@sangfor.com.cn, kunwu.chan@gmail.com
Subject: Re: [RESEND RFC PATCH v2 5/5] mm/damon/vaddr: implement DAMOS_SPLIT handler
Date: Thu, 2 Jul 2026 13:18:14 -0700 [thread overview]
Message-ID: <20260702201814.92375-1-sj@kernel.org> (raw)
In-Reply-To: <20260702094633.75658-6-lianux.mm@gmail.com>
On Thu, 2 Jul 2026 17:46:33 +0800 Lian Wang <lianux.mm@gmail.com> wrote:
> Implement the vaddr operations layer handler for DAMOS_SPLIT.
> For each folio in the target region that is larger than the
> scheme's target_order, split it via split_folio_to_order().
>
> This supports both anonymous and file-backed (e.g. tmpfs/shmem)
> folios, covering KVM guest memory backed by THP tmpfs.
>
> Signed-off-by: Lian Wang <lianux.mm@gmail.com>
> Signed-off-by: Lian Wang <lianux.wang@processmission.com>
Let's use single S-o-b: if it works.
> ---
> mm/damon/vaddr.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
>
> diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> index 98a87609376b..a177703f7e0a 100644
> --- a/mm/damon/vaddr.c
> +++ b/mm/damon/vaddr.c
> @@ -944,6 +944,83 @@ static unsigned long damos_va_collapse(struct damon_target *target,
> return applied;
> }
>
> +static unsigned long damos_va_split(struct damon_target *target,
> + struct damon_region *r, struct damos *s,
> + unsigned long *sz_filter_passed)
> +{
> + unsigned long addr, end, chunk_sz;
> + unsigned int target_order = s->target_order;
> + unsigned long applied = 0;
> + struct mm_struct *mm;
> + struct vm_area_struct *vma;
> + struct folio *folio;
> + struct folio_walk fw;
> +
> + mm = damon_get_mm(target);
> + if (!mm)
> + return 0;
> +
> + chunk_sz = PAGE_SIZE << HPAGE_PMD_ORDER;
> + addr = ALIGN_DOWN(r->ar.start, chunk_sz);
> + end = ALIGN(r->ar.end, chunk_sz);
Like I commented to collapse part, would it make more sense to ALIGN() addr and
ALIGN_DOWN() end?
> + if (end < addr)
> + goto out_mmput;
> +
> + while (addr < end) {
Above 'if (end < addr)' seems unnecessary, as while() here is covering it?
> + unsigned long folio_sz;
> +
> + if (addr + chunk_sz < addr)
> + break;
What's the purpose here? Preventing overflow? How the overflow can happen,
and what is the consequence?
> +
> + mmap_read_lock(mm);
> + vma = find_vma(mm, addr);
> +
> + if (!vma || addr < vma->vm_start ||
> + vma->vm_flags & (VM_HUGETLB | VM_MIXEDMAP))
> + goto unlock;
> +
> + folio = folio_walk_start(&fw, vma, addr, 0);
Why we need this? Can't we use the simpler pattern like that on
damos_va_stat_pmd_entry()?
> + if (!folio)
> + goto unlock;
> +
> + folio_sz = PAGE_SIZE << folio_order(folio);
You can use folio_size().
> +
> + if (folio_order(folio) > target_order) {
> + if (!folio_trylock(folio)) {
> + folio_walk_end(&fw, vma);
> + goto unlock;
> + }
> + folio_get(folio);
> + folio_walk_end(&fw, vma);
> +
> + if (!split_folio_to_order(folio, target_order))
> + applied += folio_sz;
> +
> + folio_unlock(folio);
> + folio_put(folio);
> + *sz_filter_passed += folio_sz;
Shoudn't this code calls damos_va_filter_out() before split_folio_to_order()?
> + addr += folio_sz;
> + } else {
> + folio_walk_end(&fw, vma);
> + *sz_filter_passed += chunk_sz;
> + addr += chunk_sz;
> + }
> + mmap_read_unlock(mm);
> + cond_resched();
> + continue;
> +
> +unlock:
> + *sz_filter_passed += chunk_sz;
> + addr += chunk_sz;
> + mmap_read_unlock(mm);
> + cond_resched();
> + }
> +
> +out_mmput:
> + mmput(mm);
> + return applied;
> +}
> +
> static unsigned long damon_va_apply_scheme(struct damon_ctx *ctx,
> struct damon_target *t, struct damon_region *r,
> struct damos *scheme, unsigned long *sz_filter_passed)
> @@ -977,6 +1054,9 @@ static unsigned long damon_va_apply_scheme(struct damon_ctx *ctx,
> return damos_va_migrate(t, r, scheme, sz_filter_passed);
> case DAMOS_STAT:
> return damos_va_stat(t, r, scheme, sz_filter_passed);
> + case DAMOS_SPLIT:
> + return damos_va_split(t, r, scheme,
> + sz_filter_passed);
Let's keep the order same to that of damos_action.
> default:
> /*
> * DAMOS actions that are not yet supported by 'vaddr'.
Thanks,
SJ
next prev parent reply other threads:[~2026-07-02 20:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 9:46 [RESEND RFC PATCH v2 0/5] mm/damon: add mTHP collapse and split actions Lian Wang
2026-07-02 9:46 ` [RESEND RFC PATCH v2 1/5] mm/damon: add target_order field for DAMOS_COLLAPSE Lian Wang
2026-07-02 10:01 ` sashiko-bot
2026-07-02 18:51 ` SJ Park
2026-07-02 9:46 ` [RESEND RFC PATCH v2 2/5] mm/khugepaged: add damon_collapse_folio_range() for external callers Lian Wang
2026-07-02 10:13 ` sashiko-bot
2026-07-02 11:07 ` Lorenzo Stoakes
2026-07-02 19:43 ` SJ Park
2026-07-02 20:32 ` SJ Park
2026-07-02 9:46 ` [RESEND RFC PATCH v2 3/5] mm/damon/vaddr: implement mTHP-aware DAMOS_COLLAPSE handler Lian Wang
2026-07-02 10:26 ` sashiko-bot
2026-07-02 19:56 ` SJ Park
2026-07-02 9:46 ` [RESEND RFC PATCH v2 4/5] mm/damon: introduce DAMOS_SPLIT action Lian Wang
2026-07-02 10:41 ` sashiko-bot
2026-07-02 20:00 ` SJ Park
2026-07-02 9:46 ` [RESEND RFC PATCH v2 5/5] mm/damon/vaddr: implement DAMOS_SPLIT handler Lian Wang
2026-07-02 10:49 ` sashiko-bot
2026-07-02 20:18 ` SJ Park [this message]
2026-07-02 10:23 ` [RESEND RFC PATCH v2 0/5] mm/damon: add mTHP collapse and split actions Lorenzo Stoakes
2026-07-02 16:52 ` SJ Park
2026-07-02 18:35 ` SJ Park
2026-07-02 20:50 ` SJ Park
-- strict thread matches above, loose matches on Subject: below --
2026-07-02 9:52 Lian Wang
2026-07-02 9:52 ` [RESEND RFC PATCH v2 5/5] mm/damon/vaddr: implement DAMOS_SPLIT handler Lian Wang
2026-07-02 10:30 ` sashiko-bot
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=20260702201814.92375-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=daichaobing@sangfor.com.cn \
--cc=damon@lists.linux.dev \
--cc=kunwu.chan@gmail.com \
--cc=lianux.mm@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox