All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbirs@nvidia.com>
To: Alistair Popple <apopple@nvidia.com>
Cc: Zi Yan <ziy@nvidia.com>,
	"David Hildenbrand (Arm)" <david@kernel.org>,
	 John Hubbard <jhubbard@nvidia.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Jason Gunthorpe <jgg@ziepe.ca>, Peter Xu <peterx@redhat.com>,
	Mike Rapoport <rppt@kernel.org>,
	 LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, Sourab Gupta <sougupta@nvidia.com>
Subject: Re: [PATCH] mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios
Date: Thu, 11 Jun 2026 11:12:46 +1000	[thread overview]
Message-ID: <aioG_ko6HoOv8qlc@parvat> (raw)
In-Reply-To: <aioFswTdZCdPGjag@nvdebian.thelocal>

On Thu, Jun 11, 2026 at 10:49:59AM +1000, Alistair Popple wrote:
> On 2026-06-06 at 02:20 +1000, Zi Yan <ziy@nvidia.com> wrote...
> > On 5 Jun 2026, at 5:22, David Hildenbrand (Arm) wrote:
> > 
> > > On 6/5/26 07:17, Alistair Popple wrote:
> > >> On 2026-05-15 at 10:09 +1000, Balbir Singh <balbirs@nvidia.com> wrote...
> > >>> On 4/9/26 17:52, David Hildenbrand (Arm) wrote:
> > >>>>
> > >>>> Hm, what if secretmem folio just got truncated? I hate to rely on some
> > >>>> handling in the caller to detect truncation differently during GUP-fast,
> > >>>> but this function returning "true".
> > >>>>
> > >>>
> > >>> Can secretmem folios be truncated? I assume you are referring to
> > >>> ftruncate(), I am looking at the setattr implementation of secretmem
> > >>> and it does not seem like it can be truncated.
> > >>>
> > >>>> Zi is working on a way to distinguish folios from non-folio things: that
> > >>>> we can identify whatever was added through vm_insert_page().
> > >>>>
> > >>>> Because that's really the key problem here: vm_insert_page() pages are
> > >>>> not actually folios, they just look like a folio today, but looking at
> > >>>> fields like ->mapping does not make any sense.
> > >>>>
> > >>>
> > >>> I still think this is a short term fix worth having until we get
> > >>> Zi's fixes
> > >>
> > >> Agreed - this clearly results in a performance regression and we have customers
> > >> reporting it as such. I think Zi might be out of the office atm but when I last
> > >> spoke to him he agreed this fix should go in for now and his approach will come
> > >> later.
> > >
> > > He should be back now. But yeah, let's get this fix in.
> > 
> > Right, I will work on my solution soon. Meanwhile, this change
> > is simpler and can be easily back ported.
> 
> Thanks.
> 
> > BTW, should it be back ported to older kernels?
> 
> Yes to any with f002882ca369 ("mm: merge folio_is_secretmem() and
> folio_fast_pin_allowed() into gup_fast_folio_allowed()") - we have got bug
> reports as a result of the lowered perf that commit causes.
> 
>  - Alistair
> 

Ping @akpm to pick this up, if there is no objection @david

Balbir


  reply	other threads:[~2026-06-11  1:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09  1:46 [PATCH] mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios John Hubbard
2026-04-09  2:07 ` Andrew Morton
2026-04-09  2:09   ` John Hubbard
2026-04-09  7:52 ` David Hildenbrand (Arm)
2026-04-09 15:05   ` Zi Yan
2026-04-09 15:11     ` David Hildenbrand (Arm)
2026-04-09 16:55       ` Zi Yan
2026-04-09 17:31         ` David Hildenbrand (Arm)
2026-04-09 17:33           ` Zi Yan
2026-05-15  0:09   ` Balbir Singh
2026-05-18  9:42     ` David Hildenbrand (Arm)
2026-06-05  5:17     ` Alistair Popple
2026-06-05  9:22       ` David Hildenbrand (Arm)
2026-06-05 16:20         ` Zi Yan
2026-06-11  0:49           ` Alistair Popple
2026-06-11  1:12             ` Balbir Singh [this message]
2026-06-11  7:35               ` 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=aioG_ko6HoOv8qlc@parvat \
    --to=balbirs@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=david@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=rppt@kernel.org \
    --cc=sougupta@nvidia.com \
    --cc=ziy@nvidia.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.