From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 B556F411A01 for ; Mon, 3 Aug 2026 14:47:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785768461; cv=none; b=JNvbXwaAF3AmgpWmwBMx6djqJGDgIxd8nhDtcTGOF5RVADKqSdL9vqJGckP6KueWSkJlIm2z6NVNo5MEpraYwsII6rGDPmb9v/ZGHXPaSp8n+GYNN0tnKP5SfubXf3XgBBgSr5jJXSxQNg0waOvtBzhpFIDSzgM1Iysunb7hLVM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785768461; c=relaxed/simple; bh=rKGtsx4y/TPma5rOOYzl/5ziJsjOGhB+IxmJVBq9qH0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MWl2fsZrWniaYbUJLI0Tck2+WS3BqQvvAuMnEVx5uNqtPc5dmutqDCquql5vedPGaATVKd50cYtyMiUZwQZgRfkAjF71pKWiaehDIvSNkJCRNunS/ELhvMBluo2UESKyWlZDhRNhqlH/YFev+wu1AFrrxn/bBms9AZUbVY+x3Ak= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nhfvJWU4; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nhfvJWU4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4C871F00A3E; Mon, 3 Aug 2026 14:47:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785768459; bh=c0EAKf8A0GnBdHePkQ6maEdXl/7QvO18LuwY19Dez60=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=nhfvJWU4aQxawKfpm5J7RklUcx9M21dt/pMTGDEaSSwV48U4YQlHqyHOPo/gxBbHO NGLIx8qLNt+AE/hLO8Qk1JlI9zYJM5a9WbADVTEJtNEQlUJFt6w5ymrwOO4agYMHqU 1hxXMdTQn97AZhTHV/rCnJ5AXjsumYUxVoLAGyUpgKOfsgjSSBHg75f0VR0+bG08pZ 2pUE/vd6SjLY6FQnmBoO9TdXtIxHtLeOWqyf8DX1ZaEkugMKdIbKUOixNKqvJ0gC5a 3GfqSolRK0K1yODMwIk4z52THrG1Z1jcvlQaeIl5G8o/iuH+6JHetHLA+xkGgMzidw ydW+ZZjR4y6+Q== Date: Mon, 3 Aug 2026 15:47:22 +0100 From: "Lorenzo Stoakes (ARM)" To: Rik van Riel Cc: linux-kernel@vger.kernel.org, Andrew Morton , David Hildenbrand , kernel-team@meta.com, Jason Gunthorpe , John Hubbard , Peter Xu , linux-mm@kvack.org Subject: Re: [PATCH 0/5] mm/gup: batch contiguous pages in follow_page_mask() Message-ID: References: <20260801031540.2742891-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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260801031540.2742891-1-riel@surriel.com> Why was this un-RFC'd? The only review the RFC received was 'please don't send unfiltered AI slop'? :) On Fri, Jul 31, 2026 at 11:15:35PM -0400, Rik van Riel wrote: > follow_page_mask() walks the page tables one page at a time, even when > the caller asked for a whole run of contiguous pages. Every page of a > large folio re-enters the pmd/pud/pte walk and re-takes the page table > lock. > > This series changes follow_page_mask() to return a page count and a > new @end argument bounding how many pages remain, instead of a single > struct page, so a walker can hand back more than one page per call. > > Patch 1 converts the follow_page_mask()/follow_p4d_mask()/ > follow_pud_mask()/follow_pmd_mask()/follow_page_pte() call chain to > return a long instead of a struct page pointer or ERR_PTR(), with no > functional change: every path still handles exactly one page. > > Patch 2 is pure code motion, splitting the "commit to a resolved page" > tail of follow_page_pte() into its own follow_page_pte_commit(), no > functional change. > > Patch 3 adds gup_fill_pages(), a small helper that fills pages[] and > flushes caches for a run of subpages, and converts the three existing > per-page call sites to use it with nr == 1, no functional change. > > Patch 4 has follow_huge_pud()/follow_huge_pmd() report the huge page's > real subpage count instead of a separate *page_mask output, and > retires *page_mask and __get_user_pages()'s dead second > try_grab_folio() call and subpage loop. > > It also defers gup_fill_pages() past the pud/pmd unlock, so a 1 GB > PUD-mapped folio doesn't hold that lock for a full array fill and > cache flush. > > Patch 5 adds follow_pte_batch() and has follow_page_pte() call it once > per contiguous same-folio run instead of once per page, so a > PTE-mapped mTHP no longer restarts the walk and re-takes the PTE lock > per subpage. > > This is the only patch that changes the number of page table walks or > lock acquisitions. > > Benchmarked with mm/gup_test.c (PIN_LONGTERM_BENCHMARK, pin_user_pages > + FOLL_LONGTERM, 256 MB region, median of 16 runs, folio formation > verified via the per-size anon_fault_alloc counter): > > before after > 4 kB base pages 2721 us 1198 us (2.3x) > 64 kB mTHP 2929 us 201 us (14.6x) > 2 MB THP 73 us 69 us (flat) > > The 4 kB result comes entirely from patch 5 merging two separate > try_grab_folio() calls and lock acquisitions into one; folio size and > PTE batching play no part in it. > > 64 kB mTHP adds the walk-restart avoidance on top. 2 MB THP is > unaffected, since follow_huge_pmd() already handled it in one call. > > Patch 4's lock-hold-time change is a scalability argument, not a > measured one -- it is not visible in this single-threaded benchmark. > > Suggested-by: David Hildenbrand > > Rik van Riel (5): > mm/gup: convert follow_page_mask() to return a long > mm/gup: split follow_page_pte_commit() out of follow_page_pte() > mm/gup: add gup_fill_pages() and use it > mm/gup: return a huge page's full count from follow_page_mask() > mm/gup: walk multiple PTEs per follow_page_pte() call > > mm/gup.c | 532 +++++++++++++++++++++++++++++++++---------------------- > 1 file changed, 322 insertions(+), 210 deletions(-) > No link to https://lore.kernel.org/all/20260730035350.1fc95dd8@fangorn/ or change log to indicate that this is the un-RFC'd version of that (or indicating why you un-RFC'd it)? > base-commit: fc02acf6ac0c > -- > 2.53.0-Meta -- Cheers, Lorenzo