From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5DB41FF1C4; Mon, 1 Dec 2025 08:16:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764577018; cv=none; b=tCQJTd4N6EzVUxWiOUvt/cgpKybvSzbBBq5IpW+z5Aij1KGytrzN90YHl//0vSit7RjgWE31AlPVEK03OjfuKh0y50slVGZ9vL1cu18ABisSVk0iwDWeE+dQcEU7MQqNAenXoy7GWtYpI1UeKebHecLzasvHlQz3TzswJz4c9/I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764577018; c=relaxed/simple; bh=SjCMyB1dHNwtgPTS0MoHLJhuhnjVA2MdD0tj6aAiy7Q=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=EDqJxsx+kzutAxL3n35Gr0H2M4fPfV17LYG1Kc5K9U8kwTZ4E9S5Bd2RiseSDVsBDVLDSKj5BT6+R9smsu/fahgUr321uYZ9rdAWqx2w0kkRPQx0uE9TcwSQfKaqqFJoXBPaJEIr8sNSliVy6ujGUzkM8skGpJ3K5q/dCeCkwFQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=MtQNiUA8; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="MtQNiUA8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1764577014; bh=SjCMyB1dHNwtgPTS0MoHLJhuhnjVA2MdD0tj6aAiy7Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MtQNiUA8jUaVwIUGbuaTBXQWC/AgCctwBHVMPb+164YHYlYfjkrYFBJELoRP0VqGb P9DYysHwyY9kNkN4LfOU3AU5gV+OjAkHy48NAyqKLDB8GeZLuhfjPlr524yI4a4YzQ VvkTxUKOq+PtulTUbIbaODh1Xj+fWtWz3HKq+LS9iTVwP6xLmecWck7pwCi9gQY0uJ PXBtYQTRV2aQxBC+xkYBfdJZjqFfX0pf0/lyTxNAzTFkL6Dy0RMJxjTzXr59VDelRL 5V6fNUFWH+w1H0gQT+gSiwBWn38MemyT2zTpwxcnhY2dHLO3SE5/VWksC+H8btMcPI nfEFt6sQabtYw== Received: from fedora (unknown [IPv6:2a01:e0a:2c:6930:d919:a6e:5ea1:8a9f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 9CCE617E126B; Mon, 1 Dec 2025 09:16:53 +0100 (CET) Date: Mon, 1 Dec 2025 09:16:50 +0100 From: Boris Brezillon To: =?UTF-8?B?TG/Dr2M=?= Molinari Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , Rob Herring , Steven Price , Liviu Dudau , Melissa Wen , =?UTF-8?B?TWHDrXJh?= Canal , Hugh Dickins , Baolin Wang , Andrew Morton , Al Viro , =?UTF-8?B?TWlrb8WCYWo=?= Wasiak , Christian Brauner , Nitin Gote , Andi Shyti , Jonathan Corbet , Christopher Healy , Matthew Wilcox , Bagas Sanjaya , 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 v10 02/10] drm/shmem-helper: Map huge pages in fault handler Message-ID: <20251201091650.4c45e494@fedora> In-Reply-To: <20251128185252.3092-3-loic.molinari@collabora.com> References: <20251128185252.3092-1-loic.molinari@collabora.com> <20251128185252.3092-3-loic.molinari@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 28 Nov 2025 19:52:44 +0100 Lo=C3=AFc Molinari wrote: > Attempt a PMD sized PFN insertion into the VMA if the faulty address > of the fault handler is part of a huge page. >=20 > On builds with CONFIG_TRANSPARENT_HUGEPAGE enabled, if the mmap() user > address is PMD size aligned, if the GEM object is backed by shmem > buffers on mountpoints setting the 'huge=3D' option and if the shmem > backing store manages to allocate a huge folio, CPU mapping would then > benefit from significantly increased memcpy() performance. When these > conditions are met on a system with 2 MiB huge pages, an aligned copy > of 2 MiB would raise a single page fault instead of 4096. >=20 > v4: > - implement map_pages instead of huge_fault >=20 > v6: > - get rid of map_pages handler for now (keep it for another series > along with arm64 contpte support) >=20 > Signed-off-by: Lo=C3=AFc Molinari > --- > drivers/gpu/drm/drm_gem_shmem_helper.c | 55 +++++++++++++++++++++----- > 1 file changed, 46 insertions(+), 9 deletions(-) >=20 > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm= _gem_shmem_helper.c > index be89be1c804c..81f4ac7cb8f6 100644 > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c > @@ -567,31 +567,68 @@ int drm_gem_shmem_dumb_create(struct drm_file *file= , struct drm_device *dev, > } > EXPORT_SYMBOL_GPL(drm_gem_shmem_dumb_create); > =20 > +static bool drm_gem_shmem_fault_is_valid(struct drm_gem_object *obj, > + pgoff_t pgoff) AFAICT, extracting the fault_is_valid() logic into a helper is orthogonal to the huge_page mapping stuff, and I don't see it being used in the rest of the series (I guess it was when you were introducing support for map_pages()). Maybe this should be done in a separate patch, or postponed until there's a second place checking for fault validity, dunno. > +{ > + struct drm_gem_shmem_object *shmem =3D to_drm_gem_shmem_obj(obj); > + > + if (drm_WARN_ON_ONCE(obj->dev, !shmem->pages) || > + pgoff >=3D (obj->size >> PAGE_SHIFT) || > + shmem->madv < 0) > + return false; > + > + return true; > +} > + > +static bool drm_gem_shmem_map_pmd(struct vm_fault *vmf, unsigned long ad= dr, > + struct page *page) nit: could we name that one drm_gem_shmem_try_map_pmd()? With my two nits addressed, the patch is Reviewed-by: Boris Brezillon > +{ > +#ifdef CONFIG_ARCH_SUPPORTS_PMD_PFNMAP > + unsigned long pfn =3D page_to_pfn(page); > + unsigned long paddr =3D pfn << PAGE_SHIFT; > + bool aligned =3D (addr & ~PMD_MASK) =3D=3D (paddr & ~PMD_MASK); > + > + if (aligned && > + pmd_none(*vmf->pmd) && > + folio_test_pmd_mappable(page_folio(page))) { > + pfn &=3D PMD_MASK >> PAGE_SHIFT; > + if (vmf_insert_pfn_pmd(vmf, pfn, false) =3D=3D VM_FAULT_NOPAGE) > + return true; > + } > +#endif > + > + return false; > +} > + > static vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf) > { > struct vm_area_struct *vma =3D vmf->vma; > struct drm_gem_object *obj =3D vma->vm_private_data; > struct drm_gem_shmem_object *shmem =3D to_drm_gem_shmem_obj(obj); > - loff_t num_pages =3D obj->size >> PAGE_SHIFT; > - vm_fault_t ret; > - struct page *page; > + struct page **pages =3D shmem->pages; > pgoff_t page_offset; > + unsigned long pfn; > + vm_fault_t ret; > =20 > /* Offset to faulty address in the VMA (without the fake offset). */ > page_offset =3D vmf->pgoff - vma->vm_pgoff; > =20 > dma_resv_lock(shmem->base.resv, NULL); > =20 > - if (page_offset >=3D num_pages || > - drm_WARN_ON_ONCE(obj->dev, !shmem->pages) || > - shmem->madv < 0) { > + if (unlikely(!drm_gem_shmem_fault_is_valid(obj, page_offset))) { > ret =3D VM_FAULT_SIGBUS; > - } else { > - page =3D shmem->pages[page_offset]; > + goto out; > + } > =20 > - ret =3D vmf_insert_pfn(vma, vmf->address, page_to_pfn(page)); > + if (drm_gem_shmem_map_pmd(vmf, vmf->address, pages[page_offset])) { > + ret =3D VM_FAULT_NOPAGE; > + goto out; > } > =20 > + pfn =3D page_to_pfn(pages[page_offset]); > + ret =3D vmf_insert_pfn(vma, vmf->address, pfn); > + > + out: > dma_resv_unlock(shmem->base.resv); > =20 > return ret;