Files
linux/include/linux
Zi Yan 3fec86f8aa xarray: add xas_try_split() to split a multi-index entry
Patch series "Buddy allocator like (or non-uniform) folio split", v10.

This patchset adds a new buddy allocator like (or non-uniform) large folio
split from a order-n folio to order-m with m < n.  It reduces

1. the total number of after-split folios from 2^(n-m) to n-m+1;

2. the amount of memory needed for multi-index xarray split from 2^(n/6-m/6) to
   n/6-m/6, assuming XA_CHUNK_SHIFT=6;

3. keep more large folios after a split from all order-m folios to
   order-(n-1) to order-m folios.

For example, to split an order-9 to order-0, folio split generates 10 (or
11 for anonymous memory) folios instead of 512, allocates 1 xa_node
instead of 8, and leaves 1 order-8, 1 order-7, ..., 1 order-1 and 2
order-0 folios (or 4 order-0 for anonymous memory) instead of 512 order-0
folios.

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.  I also
semi-replicated Hugh's test[12] and ran it without any issue for almost 24
hours.


This patch (of 8):

A preparation patch for non-uniform folio split, which always split a
folio into half iteratively, and minimal xarray entry split.

Currently, xas_split_alloc() and xas_split() always split all slots from a
multi-index entry.  They cost the same number of xa_node as the
to-be-split slots.  For example, to split an order-9 entry, which takes
2^(9-6)=8 slots, assuming XA_CHUNK_SHIFT is 6 (!CONFIG_BASE_SMALL), 8
xa_node are needed.  Instead xas_try_split() is intended to be used
iteratively to split the order-9 entry into 2 order-8 entries, then split
one order-8 entry, based on the given index, to 2 order-7 entries, ...,
and split one order-1 entry to 2 order-0 entries.  When splitting the
order-6 entry and a new xa_node is needed, xas_try_split() will try to
allocate one if possible.  As a result, xas_try_split() would only need 1
xa_node instead of 8.

When a new xa_node is needed during the split, xas_try_split() can try to
allocate one but no more.  -ENOMEM will be return if a node cannot be
allocated.  -EINVAL will be return if a sibling node is split or cascade
split happens, where two or more new nodes are needed, and these are not
supported by xas_try_split().

xas_split_alloc() and xas_split() split an order-9 to order-0:

         ---------------------------------
         |   |   |   |   |   |   |   |   |
         | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
         |   |   |   |   |   |   |   |   |
         ---------------------------------
           |   |                   |   |
     -------   ---               ---   -------
     |           |     ...       |           |
     V           V               V           V
----------- -----------     ----------- -----------
| xa_node | | xa_node | ... | xa_node | | xa_node |
----------- -----------     ----------- -----------

xas_try_split() splits an order-9 to order-0:
   ---------------------------------
   |   |   |   |   |   |   |   |   |
   | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
   |   |   |   |   |   |   |   |   |
   ---------------------------------
     |
     |
     V
-----------
| xa_node |
-----------

Link: https://lkml.kernel.org/r/20250307174001.242794-1-ziy@nvidia.com
Link: https://lkml.kernel.org/r/20250307174001.242794-2-ziy@nvidia.com
Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Kirill A. Shuemov <kirill.shutemov@linux.intel.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Yang Shi <yang@os.amperecomputing.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: Kairui Song <kasong@tencent.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-17 22:06:59 -07:00
..
2024-10-22 15:54:11 +02:00
2024-10-11 14:34:11 -04:00
2024-10-13 17:16:57 +02:00
2024-10-11 14:37:29 +05:30
2024-10-14 23:27:57 +05:30
2024-11-11 10:45:03 +01:00
2024-10-09 15:42:48 +01:00
2025-01-04 15:27:35 -07:00
2025-03-06 17:50:55 -07:00
2024-10-14 18:33:04 -07:00
2025-01-06 07:36:39 -07:00
2024-06-24 18:29:20 +02:00
2025-01-18 12:33:39 -08:00
2025-03-17 22:06:41 -07:00
2024-06-11 12:57:49 -05:00
2024-11-05 13:32:21 +01:00
2024-10-22 11:16:56 +02:00
2024-12-17 09:16:11 +01:00
2024-10-19 14:16:45 +02:00
2025-01-25 20:22:31 -08:00
2024-11-09 14:55:33 +01:00
2024-11-28 14:49:28 +01:00
2025-01-09 10:06:14 +01:00
2024-08-29 10:39:37 +02:00
2025-01-07 18:06:51 -08:00
2024-11-24 17:05:27 -08:00
2024-12-18 09:39:37 +01:00
2024-07-31 13:49:48 +01:00
2024-10-16 21:56:59 +02:00
2024-06-24 22:24:56 -07:00
2025-01-25 08:22:26 +00:00
2024-09-03 21:15:46 -07:00
2024-09-20 18:28:26 +03:00
2024-09-01 20:26:03 -07:00
2024-11-05 16:56:26 -08:00
2024-07-03 19:30:23 -07:00
2025-01-14 19:45:35 +01:00
2024-12-13 08:49:31 -07:00
2024-12-09 13:48:23 -08:00
2025-02-04 11:27:45 -05:00
2024-10-14 16:33:24 -05:00
2025-03-17 22:06:39 -07:00
2024-08-11 17:04:29 +01:00
2025-03-17 22:06:53 -07:00
2025-03-17 22:06:39 -07:00
2025-01-15 15:07:23 -08:00
2025-02-25 15:07:24 -05:00
2024-09-23 15:03:30 -04:00
2024-06-24 22:25:02 -07:00
2024-11-05 16:56:26 -08:00
2025-03-16 22:06:22 -07:00
2024-08-30 08:22:38 +02:00
2025-02-10 09:22:32 +01:00
2024-11-16 10:09:30 -06:00
2024-10-02 16:23:10 -05:00
2025-03-17 00:05:34 -07:00
2025-01-16 17:22:59 -08:00
2024-12-22 11:03:10 +01:00
2025-01-10 11:59:00 +01:00
2025-01-07 15:16:48 +01:00
2024-11-05 12:55:38 +01:00
2025-03-16 17:40:22 -07:00
2025-01-02 10:37:14 -06:00
2024-12-09 14:44:59 -08:00
2025-01-08 14:50:11 -08:00
2024-09-11 20:44:31 -07:00
2024-12-19 19:51:13 -08:00
2025-01-29 13:32:23 -08:00
2025-03-16 22:06:21 -07:00
2025-01-29 09:04:28 -08:00
2024-07-10 07:59:03 +02:00
2024-11-06 12:59:44 -05:00
2024-10-02 16:53:38 +02:00
2024-08-06 13:42:40 +02:00
2024-11-18 11:56:21 +00:00
2024-12-23 08:17:16 -07:00
2024-06-24 18:16:44 +01:00
2024-12-09 14:44:59 -08:00
2024-11-06 12:59:44 -05:00