From: Andrew Morton <akpm@linux-foundation.org>
To: Peter Xu <peterx@redhat.com>
Cc: Lokesh Gidra <lokeshgidra@google.com>,
aarcange@redhat.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, 21cnbao@gmail.com,
ngeoffray@google.com, Suren Baghdasaryan <surenb@google.com>,
Kalesh Singh <kaleshsingh@google.com>,
Barry Song <v-songbaohua@oppo.com>,
David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH v3] userfaultfd: opportunistic TLB-flush batching for present pages in MOVE
Date: Thu, 7 Aug 2025 15:54:01 -0700 [thread overview]
Message-ID: <20250807155401.683c77b0d0cb5c9ec88089e6@linux-foundation.org> (raw)
In-Reply-To: <aJT7qQzEs_p36yfI@x1.local>
On Thu, 7 Aug 2025 15:16:57 -0400 Peter Xu <peterx@redhat.com> wrote:
> Hi, Lokesh,
>
> On Thu, Aug 07, 2025 at 03:39:02AM -0700, Lokesh Gidra wrote:
> > MOVE ioctl's runtime is dominated by TLB-flush cost, which is required
> > for moving present pages. Mitigate this cost by opportunistically
> > batching present contiguous pages for TLB flushing.
> >
> > Without batching, in our testing on an arm64 Android device with UFFD GC,
> > which uses MOVE ioctl for compaction, we observed that out of the total
> > time spent in move_pages_pte(), over 40% is in ptep_clear_flush(), and
> > ~20% in vm_normal_folio().
> >
> > With batching, the proportion of vm_normal_folio() increases to over
> > 70% of move_pages_pte() without any changes to vm_normal_folio().
>
> Do you know why vm_normal_folio() could be expensive? I still see quite
> some other things this path needs to do.
Maybe as explained here?
https://lkml.kernel.org/r/20250807185819.199865-1-lorenzo.stoakes@oracle.com
next prev parent reply other threads:[~2025-08-07 22:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-07 10:39 [PATCH v3] userfaultfd: opportunistic TLB-flush batching for present pages in MOVE Lokesh Gidra
2025-08-07 19:16 ` Peter Xu
2025-08-07 22:54 ` Andrew Morton [this message]
2025-08-08 16:41 ` Lokesh Gidra
2025-08-08 16:29 ` Lokesh Gidra
2025-08-10 6:31 ` Lokesh Gidra
2025-08-11 14:00 ` Peter Xu
2025-08-12 14:01 ` Lokesh Gidra
2025-08-08 6:18 ` Dan Carpenter
2025-08-08 15:27 ` Lokesh Gidra
-- strict thread matches above, loose matches on Subject: below --
2025-08-07 22:24 kernel test robot
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=20250807155401.683c77b0d0cb5c9ec88089e6@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=21cnbao@gmail.com \
--cc=aarcange@redhat.com \
--cc=david@redhat.com \
--cc=kaleshsingh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lokeshgidra@google.com \
--cc=ngeoffray@google.com \
--cc=peterx@redhat.com \
--cc=surenb@google.com \
--cc=v-songbaohua@oppo.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.