All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SeongJae Park <sj@kernel.org>,
	"Kefeng Wang" <wangkefeng.wang@huawei.com>,
	damon@lists.linux.dev, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v2] mm/damon/vaddr: attempt per-vma lock during page table walk
Date: Wed, 13 May 2026 18:50:52 -0700	[thread overview]
Message-ID: <20260514015053.149396-1-sj@kernel.org> (raw)
In-Reply-To: <20260513225204.4157FC19425@smtp.kernel.org>

On Wed, 13 May 2026 22:52:03 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] `damos_va_migrate_pmd_entry` and `damos_va_stat_pmd_entry` incorrectly advance iteration by the full folio size, skipping unrelated PTEs for mTHP.
> --
> 
> commit 25c04a646a951de8c86c5c718af6cfc459b7b5e0
> Author: Kefeng Wang <wangkefeng.wang@huawei.com>
> 
> mm/damon/vaddr: attempt per-vma lock during page table walk
> 
> Currently, DAMON virtual address operations use mmap_read_lock
> during page table walks, which can cause unnecessary contention
> under high concurrency.
> 
> > diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> > index 1b0ebe3b6951e..d271476035641 100644
> > --- a/mm/damon/vaddr.c
> > +++ b/mm/damon/vaddr.c
> [ ... ]
> > @@ -750,7 +773,6 @@ static unsigned long damos_va_migrate(struct damon_target *target,
> >  	struct mm_walk_ops walk_ops = {
> >  		.pmd_entry = damos_va_migrate_pmd_entry,
> >  		.pte_entry = NULL,
> > -		.walk_lock = PGWALK_RDLOCK,
> >  	};
> 
> This isn't a regression from this patch,

Yes, no blocker for this patch.

> but there appears to be a pre-existing
> issue in damos_va_migrate_pmd_entry() and damos_va_stat_pmd_entry() when
> handling large folios.
> 
> In the PTE iteration loops, when a large folio is found, the code sets
> nr = folio_nr_pages(folio) and updates pte += nr and addr += nr * PAGE_SIZE.
> 
> Could this skip unrelated PTEs if the iteration started on a tail page of this
> folio (e.g., halfway into an mTHP)?
> 
> Advancing by the full folio size could overshoot the end of the folio and skip
> unrelated PTEs mapped immediately after it within the same PMD.
> 
> Would it be better to subtract the offset within the folio to safely skip only
> the remaining pages of the current folio?

The user impact should be minor, but makes sense.  I will work on this.


Thanks,
SJ

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260512151523.2092638-1-wangkefeng.wang@huawei.com?part=1

  reply	other threads:[~2026-05-14  1:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-12 15:15 [PATCH v2] mm/damon/vaddr: attempt per-vma lock during page table walk Kefeng Wang
2026-05-13 22:52 ` sashiko-bot
2026-05-14  1:50   ` SeongJae Park [this message]
2026-05-14  2:00 ` SeongJae Park
2026-05-14 11:13   ` Kefeng Wang

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=20260514015053.149396-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-bot@kernel.org \
    --cc=wangkefeng.wang@huawei.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.