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

[Jacob Martin]

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.

-- 
2.43.0