From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9EEA3CCD195 for ; Fri, 17 Oct 2025 21:43:21 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0AAC410E043; Fri, 17 Oct 2025 21:43:21 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=infradead.org header.i=@infradead.org header.b="Pb3rtC4R"; dkim-atps=neutral Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by gabe.freedesktop.org (Postfix) with ESMTPS id A49AF10E043; Fri, 17 Oct 2025 21:43:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=x7o2YWfTYWvvpeEx4JrqhbgEy4JzUWFniUNRW6oSBlM=; b=Pb3rtC4RdF2NsCYvJ4A9cC5+o5 DV8vVeeFeVXh5fcNYXzcVmqJP8Vx6kBRhiYXuemDo+IX6LkKZWcKJRv1Ej0vSH3AVNBFG40U6V6Sa oa2CFHVvwLl+7WzdLCg34ITSujSABfuuu4RppYXDdrzwkuVJlveiuSnDFyloJa/RUQ5RZXDRHfqqh 1sA6V+g5Sh/ypi1O6y0ntVjA7p+vo04vGDBaHgx2B64xqSD5vNazWjdpKGFtbuVHZbHdJyvqOZe/Z VmlxTUMp5if+N3N8KH+I9ZTl9Ohdc46Zq18kx5udsjizL5owhw8t3q1Nkr5Pk9ZmAg+2N4qM9JZHs tv/Vsh+Q==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1v9sDz-00000003bne-2gZi; Fri, 17 Oct 2025 21:42:59 +0000 Date: Fri, 17 Oct 2025 22:42:59 +0100 From: Matthew Wilcox To: =?iso-8859-1?Q?Lo=EFc?= Molinari Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , Boris Brezillon , Rob Herring , Steven Price , Liviu Dudau , Melissa Wen , =?iso-8859-1?Q?Ma=EDra?= Canal , Hugh Dickins , Baolin Wang , Andrew Morton , Al Viro , =?utf-8?Q?Miko=C5=82aj?= Wasiak , Christian Brauner , Nitin Gote , Andi Shyti , Jonathan Corbet , Christopher Healy , 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 v4 03/13] drm/shmem-helper: Map huge pages in fault handlers Message-ID: References: <20251015153018.43735-1-loic.molinari@collabora.com> <20251015153018.43735-4-loic.molinari@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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).