From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 5DEE946EF6E for ; Fri, 24 Jul 2026 22:30:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784932218; cv=none; b=DALQS+95Ae/mDe9zdjIUgSJIk4+oczgS+j2uZU8+1fSMaVIstKVZnUQYOozd763eTSvNYYB2l6NbBEHvMDQDxXQqAq52MrfutbIPFb9QAEzyndkiYHHODcXIrhxEADtkzcrkXPtjxM+ZwN5Q8Shz6cALr+BbutufNb4pkcurUfE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784932218; c=relaxed/simple; bh=0AM3kERdoP79xy3BLW7VnaebqOk3m38Tp33w3HtyIhk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dHOrCl5Taplg8gQJ0Vsu9scGXwUsNPxbk0Z0LHl33qgd5HPOWDCOCg4yWYC5APmKbK11eP9drHZcMFq0OIYIW18P2Wog2eoctfsbsaRsL0YaKbUkQHS90LXgVcEEFnfmM2TI8jE1j2YNgcYf5sXXyyXtjYIuC4dDD50O3j/WleE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=surriel.com; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b=OJksZob7; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=surriel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b="OJksZob7" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=Content-Transfer-Encoding:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=/nMsMXQjXiyA5qAYl7QT0yp1WELxZnCfyNHaXsTe27c=; b=OJksZob72/FPZ/ELTbhArp8gh9 7UMXiNlaPpudxMXOBVJMUrfH+0aQhfhpbgKO5m3p6KJ+qYxLMuUeykJu14bVfe/Ju1UpbMLNT/Qpa JEKIKeIgeB81zgqkDkbdQOIqNwsfs0Zq4gmvITvR+9M8DH0FZS0HrBtO6PampJ6y2eQJDWsY38kvo 86CVxhLsA43csRlQ5zd8+eqyGIFWYVas87aTFTGQLAk4aPUxHkl2g91w/AJAY2uR0AN9gJyEcv0LZ Cqb0CMQqR4pl5ZjnUMPZSUfOZZSZ9ajq7qGIf5+2+h2c+Zqygt7/PaQ83o9STEM9CcLRVBnuztl5e 23N8lVDA==; Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1wnOOs-0000000027h-28o2; Fri, 24 Jul 2026 18:29:50 -0400 From: Rik van Riel To: Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com, Dave Hansen , Peter Zijlstra , Suren Baghdasaryan , Lorenzo Stoakes , Vlastimil Babka , David Hildenbrand , "Liam R. Howlett" , Mike Rapoport , Michal Hocko , Jason Gunthorpe , John Hubbard , Peter Xu , Matthew Wilcox , Usama Arif , Rik van Riel Subject: [PATCH RFC v4 11/12] mm/gup: batch contiguous PTE-mapped large folios in follow_page_mask() Date: Fri, 24 Jul 2026 18:29:33 -0400 Message-ID: <20260724222934.1463812-12-riel@surriel.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260724222934.1463812-1-riel@surriel.com> References: <20260724222934.1463812-1-riel@surriel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit follow_page_mask() returns one page per call for a PTE-mapped large folio, so __get_user_pages() re-walks the page tables for every page of an mTHP even though the folio maps a contiguous run. The huge PMD and PUD paths already return the whole mapping in one step. Report the contiguous run for the PTE case too. follow_pte_batch() uses folio_pte_batch_flags() to count consecutive present PTEs that map consecutive pages of the same folio with a uniform write bit, bounded by the page table, @end, the VMA, and the folio itself. Keep the per-PTE guarantees that follow_page_pte() makes for the head page. folio_pte_batch_flags() with FPB_RESPECT_WRITE stops the run at a change in the write bit, so the whole run matches the head. A writable run is safe for any access: a writable anon page is exclusive, so gup_must_unshare() cannot fire, and FOLL_WRITE is satisfied. A read-only run is batched only for a plain read, since FOLL_WRITE would need a COW fault per page and FOLL_PIN would need a per-page gup_must_unshare() check. Measured with mm/gup_test.c (PIN_LONGTERM_BENCHMARK, the slow pin_user_pages() path) on a 256 MB MADV_HUGEPAGE anonymous region in a 4 CPU VM, median get time over 16 iterations. Each folio size was confirmed through the per-size anon_fault_alloc counters (4096 folios for 64 kB, 128 for 2 MB): gup_test -L -m 256 -n 65536 -r 16 -t before after 64 kB mTHP 3140 us 412 us (7.6x) 2 MB THP (control) 78 us 76 us 4 kB base (control) 3010 us 3042 us The PMD-mapped 2 MB THP already returns the whole mapping in one step, so it stays fast and unchanged. The 4 kB baseline shows the per-page walk cost that the 64 kB case paid before this change; only the PTE-mapped large folio case improves. Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Rik van Riel --- mm/gup.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/mm/gup.c b/mm/gup.c index 96b00ddf7e04..4910c93ba003 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -805,6 +805,43 @@ static inline bool can_follow_write_pte(pte_t pte, struct page *page, return !userfaultfd_pte_wp(vma, pte); } +/* + * Count the pages, starting at @address and bounded by @end, that a PTE-mapped + * large @folio maps contiguously and that can be returned together with the + * page at @address: consecutive present PTEs mapping consecutive pages of + * @folio with a uniform write bit, within this VMA and a single page table. + * Returns at least 1. + * + * gup_must_unshare() and the write-fault check are per PTE. A writable run is + * always safe: a writable anon page is exclusive, and FOLL_WRITE is satisfied. + * A read-only run is only safe for a plain read; FOLL_WRITE would need a COW + * fault per page and FOLL_PIN would need a per-page gup_must_unshare() check, + * so those fall back to a single page. + */ +static unsigned long follow_pte_batch(struct vm_area_struct *vma, + unsigned long address, unsigned long end, struct folio *folio, + struct page *page, pte_t *ptep, pte_t pte, unsigned int flags) +{ + pte_t batch_pte = pte; + unsigned long max; + + if (!pte_write(pte) && (flags & (FOLL_WRITE | FOLL_PIN))) + return 1; + + /* + * folio_pte_batch_flags() scans forward from @ptep, so the run must + * stay within this page table: bound it by the PMD as well as @end and + * the VMA, since a large folio can be PTE-mapped across a PMD boundary. + */ + max = min((pmd_addr_end(address, end) - address) >> PAGE_SHIFT, + (vma->vm_end - address) >> PAGE_SHIFT); + if (max <= 1) + return 1; + + return folio_pte_batch_flags(folio, vma, ptep, &batch_pte, max, + FPB_RESPECT_WRITE); +} + static struct page *follow_page_pte(struct vm_area_struct *vma, unsigned long address, unsigned long end, pmd_t *pmd, unsigned int flags, unsigned long *nr_pages) @@ -893,6 +930,14 @@ static struct page *follow_page_pte(struct vm_area_struct *vma, folio_mark_accessed(folio); } + /* + * A PTE-mapped large folio can be handed back as a contiguous batch, + * so the caller advances over the whole run in one step instead of + * walking the page tables for every page. + */ + if (folio_test_large(folio)) + *nr_pages = follow_pte_batch(vma, address, end, folio, page, + ptep, pte, flags); out: pte_unmap_unlock(ptep, ptl); return page; -- 2.53.0-Meta