APPLIED[R/N]: [SRU][S/R/N][PATCH 0/3] Resolve get_user_pages() performance regression for 0-order NULL-mapping folios

[Stefan Bader]

On 10/09/2026 15:58, Jacob Martin via kernel-team wrote:
> BugLink: https://bugs.launchpad.net/bugs/2162917
> 
> [Impact]
> 
> There is a performance regression seen for calls to get_user_pages() on
> single-page NULL-mapping folios, introduced by commit f002882ca369 ("mm: merge
> folio_is_secretmem() and folio_fast_pin_allowed() into
> gup_fast_folio_allowed()").
> 
> When either CONFIG_SECRETMEM=y, or when the folio is a long-term writable pin,
> the current implementation requires that the mapping be checked as either a
> secretmem mapping or a file-backed one. If it is either, or if the mapping is
> NULL, the slow path is forced.
> 
> However, when the mapping is NULL, the folio cannot be a secretmem mapping.
> Thus, as long as the folio is NOT a long-term writable pin, the fast path can
> still be used.
> 
> This performance regression was initially observed during GPU Direct Storage
> (GDS) workloads.
> 
> [Fix]
> 
> The upstream commit c494788faffe ("mm/gup: fix GUP-fast fallback for
> NULL-mapping order-0 folios") resolves the performance regression by changing
> gup_fast_folio_allowed() to allow the fast path for the case described above,
> where the folio is NOT a long-term writable pin and its mapping field is NULL.
> 
> [Test Plan]
> 
> Build and boot tested.
> 
> The performance regression and subsequent fix can be verified with a GDS
> workload. The original bug report also describes a test kernel module that uses
> the `alloc_page` + `vm_insert_page` + `pin_user_pages_fast(..., FOLL_WRITE,
> ...)` functions to emulate GDS behavior, and using `get_user_pages_fast_only()`
> on that to validate that the fast path is now allowed in this scenario.
> 
> [Where problems could occur]
> 
> The fix affects the get_user_pages*() path of the mm subsystem, which is used
> heavily. The fix has been reviewed and applied in upstream Linux.
> 
Applied to resolute,noble:linux/master-next. Thanks.

-Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260917/38dc4bb6/attachment.sig>