linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: "Loïc Molinari" <loic.molinari@collabora.com>
Cc: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tvrtko Ursulin" <tursulin@ursulin.net>,
	"Boris Brezillon" <boris.brezillon@collabora.com>,
	"Rob Herring" <robh@kernel.org>,
	"Steven Price" <steven.price@arm.com>,
	"Liviu Dudau" <liviu.dudau@arm.com>,
	"Melissa Wen" <mwen@igalia.com>,
	"Maíra Canal" <mcanal@igalia.com>,
	"Hugh Dickins" <hughd@google.com>,
	"Baolin Wang" <baolin.wang@linux.alibaba.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Al Viro" <viro@zeniv.linux.org.uk>,
	"Mikołaj Wasiak" <mikolaj.wasiak@intel.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"Nitin Gote" <nitin.r.gote@intel.com>,
	"Andi Shyti" <andi.shyti@linux.intel.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Christopher Healy" <healych@amazon.com>,
	"Bagas Sanjaya" <bagasdotme@gmail.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, linux-mm@kvack.org,
	linux-doc@vger.kernel.org, kernel@collabora.com
Subject: Re: [PATCH v4 03/13] drm/shmem-helper: Map huge pages in fault handlers
Date: Fri, 17 Oct 2025 22:42:59 +0100	[thread overview]
Message-ID: <aPK4YwMmYTDsKHcL@casper.infradead.org> (raw)
In-Reply-To: <f564735b-7cbd-486c-9dd4-a4555e73edde@collabora.com>

On Thu, Oct 16, 2025 at 01:17:07PM +0200, Loïc Molinari wrote:
> > It looks to me like we have an opportunity to do better here by
> > adding a vmf_insert_pfns() interface.  I don't think we should delay
> > your patch series to add it, but let's not forget to do that; it can
> > have very good performnce effects on ARM to use contptes.
> 
> Agreed. I initially wanted to provide such an interface based on set_ptes()
> to benefit from arm64 contptes but thought it'd better be a distinct patch
> series.

Agreed.

> > 
> > > @@ -617,8 +645,9 @@ static vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf)
> > [...]
> > > -		ret = vmf_insert_pfn(vma, vmf->address, page_to_pfn(page));
> > > +	if (drm_gem_shmem_map_pmd(vmf, vmf->address, pages[page_offset])) {
> > > +		ret = VM_FAULT_NOPAGE;
> > > +		goto out;
> > >   	}
> > 
> > Does this actually work?
> 
> Yes, it does. Huge pages are successfully mapped from both map_pages and
> fault handlers. Anything wrong with it?

No, I just wasn't sure that this would work correctly.

> There seems to be an another issue thought. There are failures [1], all
> looking like that one [2]. I think it's because map_pages is called with the
> RCU read lock taken and the DRM GEM map_pages handler must lock the GEM
> object before accessing pages with dma_resv_lock(). The locking doc says:
> "If it's not possible to reach a page without blocking, filesystem should
> skip it.". Unlocking the RCU read lock in the handler seems wrong and doing
> without a map_pages implementation would be unfortunate. What would you
> recommend here?

I'm not familiar with GEM locking, so let me describe briefly how
pagecache locking works.

Calling mmap bumps the refcount on the inode.  That keeps the inode
around while the page fault handler runs.  For each folio, we
get a refcount on it, then we trylock it.  Then we map each page in the
folio.

So maybe you can trylock the GEM object?  It isn't clear to me whether
you want finer grained locking than that.  If the trylock fails, no big
deal, you just fall through to the fault path (with the slightly more
heavy-weight locking that allows you to sleep).


  reply	other threads:[~2025-10-17 21:43 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15 15:30 [PATCH v4 00/13] drm: Reduce page tables overhead with THP Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 01/13] drm/shmem-helper: Simplify page offset calculation in fault handler Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 02/13] drm/shmem-helper: Implement map_pages fault-around handler Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 03/13] drm/shmem-helper: Map huge pages in fault handlers Loïc Molinari
2025-10-15 17:27   ` Matthew Wilcox
2025-10-16 11:17     ` Loïc Molinari
2025-10-17 21:42       ` Matthew Wilcox [this message]
2025-11-10 14:39         ` Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 04/13] drm/gem: Introduce drm_gem_get_unmapped_area() fop Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 05/13] drm/gem: Add huge tmpfs mount point helper Loïc Molinari
2025-10-20  9:10   ` Tvrtko Ursulin
2025-10-20 14:13     ` Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 06/13] drm/i915: Use " Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 07/13] drm/v3d: " Loïc Molinari
2025-10-20  9:33   ` Tvrtko Ursulin
2025-10-20 14:27     ` Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 08/13] drm/v3d: Fix builds with CONFIG_TRANSPARENT_HUGEPAGE=n Loïc Molinari
2025-10-15 18:17   ` Boris Brezillon
2025-10-15 20:41     ` Loïc Molinari
2025-10-16  5:56       ` Boris Brezillon
2025-10-16  7:09         ` Loïc Molinari
2025-10-16  7:22           ` Boris Brezillon
2025-10-15 15:30 ` [PATCH v4 09/13] drm/gem: Get rid of *_with_mnt helpers Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 10/13] drm/panthor: Introduce huge tmpfs mount point option Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 11/13] drm/panthor: Improve IOMMU map/unmap debugging logs Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 12/13] drm/panfrost: Introduce huge tmpfs mount point option Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 13/13] Documentation/gpu/drm-mm: Add THP paragraph to GEM mapping section Loïc Molinari

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=aPK4YwMmYTDsKHcL@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi.shyti@linux.intel.com \
    --cc=bagasdotme@gmail.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=boris.brezillon@collabora.com \
    --cc=brauner@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=healych@amazon.com \
    --cc=hughd@google.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kernel@collabora.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liviu.dudau@arm.com \
    --cc=loic.molinari@collabora.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mcanal@igalia.com \
    --cc=mikolaj.wasiak@intel.com \
    --cc=mripard@kernel.org \
    --cc=mwen@igalia.com \
    --cc=nitin.r.gote@intel.com \
    --cc=robh@kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=steven.price@arm.com \
    --cc=tursulin@ursulin.net \
    --cc=tzimmermann@suse.de \
    --cc=viro@zeniv.linux.org.uk \
    /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