mbox series

[v6,0/7] Buddy allocator like (or non-uniform) folio split

Message ID 20250205031417.1771278-1-ziy@nvidia.com
Headers show
Series Buddy allocator like (or non-uniform) folio split | expand

Message

Zi Yan Feb. 5, 2025, 3:14 a.m. UTC 
Hi all,

This patchset adds a new buddy allocator like (or non-uniform) large folio
split to reduce the total number of after-split folios, the amount of memory
needed for multi-index xarray split, and keep more large folios after a split.
It is on top of mm-everything-2025-02-01-05-58. It is ready to be merged.

Instead of duplicating existing split_huge_page*() code, __folio_split()
is introduced as the shared backend code for both
split_huge_page_to_list_to_order() and folio_split(). __folio_split()
can support both uniform split and buddy allocator like (or non-uniform) split.
All existing split_huge_page*() users can be gradually converted to use
folio_split() if possible. In this patchset, I converted
truncate_inode_partial_folio() to use folio_split().

xfstests quick group passed for both tmpfs and xfs.


Changelog
===

Comments

Andrew Morton Feb. 6, 2025, 8:01 a.m. UTC | #1 
On Tue,  4 Feb 2025 22:14:10 -0500 Zi Yan <ziy@nvidia.com> wrote:

> This patchset adds a new buddy allocator like (or non-uniform) large folio
> split to reduce the total number of after-split folios, the amount of memory
> needed for multi-index xarray split, and keep more large folios after a split.

It would be useful (vital, really) to provide some measurements which
help others understand the magnitude of these resource savings, please.