All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>,
	 linux-kernel@vger.kernel.org
Cc: kernel-team@meta.com, Andrew Morton <akpm@linux-foundation.org>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
		linux-mm@kvack.org
Subject: Re: [RFC PATCH v3 3/8] mm/gup: split follow_page_pte_commit() out of follow_page_pte()
Date: Wed, 12 Aug 2026 09:02:05 -0400	[thread overview]
Message-ID: <30b747de6202cd875b7669f8d76ad8ded5c0a4e7.camel@surriel.com> (raw)
In-Reply-To: <8a9d5a6f-a7c6-468f-8b50-a7aa2b4dea2c@kernel.org>

On Wed, 2026-08-12 at 13:50 +0200, David Hildenbrand (Arm) wrote:
> On 8/11/26 04:51, Rik van Riel wrote:
> > 
> > +/*
> > + * The caller has already run every per-PTE safety check (present,
> > + * write-fault, gup_must_unshare()) on the PTE, so this only does
> > the
> > + * per-folio work: the refcount grab, the FOLL_PIN accessibility
> > fault-in,
> > + * dirty/accessed marking, and the array fill with the cache
> > flush.
> > + */
> 
> If a function needs 4 lines of internal doc to understand what it
> does, then
> maybe it's not the right function name or abstraction. :)
> 
> I don't particularly enjoy the "commit" terminology, it looses the
> detail of the
> most important thing this function is supposed to to: grab a folio
> reference.
> 

Should we rename it to gup_grab_folio() ?

> We're passing in the pte only to do a single pte_dirty(). If the
> helper is
> actually what we want, likely we just just pass in the pte_dirty()
> directly and
> remove all pte leftovers from the helper.
> 
> I'd assume that we'd want a function where we can similarly punch in
> a PMD/PUD
> and have it do the same thing as well, instead of special-casing
> ptes.

Looking at the differences between the pte and pmd
code, there is another big thing that stands out.

The pte code will call mark_folio_dirty() when
needed, but the pmd and pud code do not.

For hugetlbfs we can get away with that, but for
huge folios coming from a filesystem, don't we
want to call mark_folio_dirty() somewhere?

I'm happy to do whatever cleanups we can do to
this code while we're here.

-- 
All Rights Reversed.


  reply	other threads:[~2026-08-12 13:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11  2:51 [RFC PATCH v3 0/8] batch lookups in follow_page_mask() Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 1/8] mm/gup: break out gup_fill_pages() helper Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 2/8] mm/gup: convert follow_page_mask() to return a long Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 3/8] mm/gup: split follow_page_pte_commit() out of follow_page_pte() Rik van Riel
2026-08-12 11:50   ` David Hildenbrand (Arm)
2026-08-12 13:02     ` Rik van Riel [this message]
2026-08-12 13:23       ` David Hildenbrand (Arm)
2026-08-12 16:19         ` Rik van Riel
2026-08-21 17:38         ` Rik van Riel
2026-08-21 22:04           ` John Hubbard
2026-08-11  2:51 ` [RFC PATCH v3 4/8] mm/gup: break out follow_one_pte() helper Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 5/8] mm/gup: fill the pages array outside the pud/pmd lock Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 6/8] mm/gup: return a huge page's full count from follow_page_mask() Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 7/8] mm/gup: walk multiple PTEs per follow_page_pte() call Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 8/8] mm/gup: batch contiguous same-folio PTEs into one refcount grab Rik van Riel
2026-08-12 11:41 ` [RFC PATCH v3 0/8] batch lookups in follow_page_mask() David Hildenbrand (Arm)

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=30b747de6202cd875b7669f8d76ad8ded5c0a4e7.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.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.