On 11.02.25 16:50, Zi Yan wrote:
folio_split() splits a large folio in the same way as buddy allocator splits a large free page for allocation. The purpose is to minimize the number of folios after the split. For example, if user wants to free the 3rd subpage in a order-9 folio, folio_split() will split the order-9 folio as: O-0, O-0, O-0, O-0, O-2, O-3, O-4, O-5, O-6, O-7, O-8 if it is anon, since anon folio does not support order-1 yet.
| | | | | | | | | |O-0|O-0|O-0|O-0| O-2 |...| O-7 | O-8 | | | | | | | | | |
O-1, O-0, O-0, O-2, O-3, O-4, O-5, O-6, O-7, O-9 if it is pagecache
| | | | | | | | | O-1 |O-0|O-0| O-2 |...| O-7 | O-8 | | | | | | | | |
It generates fewer folios (i.e., 11 or 10) than existing page split approach, which splits the order-9 to 512 order-0 folios. It also reduces the number of new xa_node needed during a pagecache folio split from 8 to 1, potentially decreasing the folio split failure rate due to memory constraints.
folio_split() and existing split_huge_page_to_list_to_order() share the folio unmapping and remapping code in __folio_split() and the common backend split code in __split_unmapped_folio() using uniform_split variable to distinguish their operations.
uniform_split_supported() and non_uniform_split_supported() are added to factor out check code and will be used outside __folio_split() in the following commit.
Signed-off-by: Zi Yan ziy@nvidia.com
mm/huge_memory.c | 137 ++++++++++++++++++++++++++++++++++------------- 1 file changed, 100 insertions(+), 37 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 21ebe2dec5a4..400dfe8a6e60 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3853,12 +3853,68 @@ static int __split_unmapped_folio(struct folio *folio, int new_order, return ret; } +static bool non_uniform_split_supported(struct folio *folio, unsigned int new_order,
bool warns)+{
- /* order-1 is not supported for anonymous THP. */
- if (folio_test_anon(folio) && new_order == 1) {
VM_WARN_ONCE(warns, "Cannot split to order-1 folio");return false;- }
- /*
* No split if the file system does not support large folio.* Note that we might still have THPs in such mappings due to* CONFIG_READ_ONLY_THP_FOR_FS. But in that case, the mapping* does not actually support large folios properly.*/- if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) &&
!mapping_large_folio_support(folio->mapping)) {
In this (and a similar case below), you need
if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && !folio_test_anon(folio) && !mapping_large_folio_support(folio->mapping)) {
Otherwise mapping_large_folio_support() is unhappy:
[root@localhost mm]# ./split_huge_page_test TAP version 13 1..20 ok 1 Split zero filled huge pages successful ok 2 Split huge pages to order 0 successful [ 144.936764][T15389] ------------[ cut here ]------------ [ 144.937948][T15389] Anonymous mapping always supports large folio [ 144.938164][T15389] WARNING: CPU: 5 PID: 15389 at ./include/linux/pagemap.h:494 uniform_split_supported+0x270/0x290 [ 144.941442][T15389] Modules linked in: [ 144.942212][T15389] CPU: 5 UID: 0 PID: 15389 Comm: split_huge_page Not tainted 6.14.0-rc2-00200-gdcbc194183fd #153 [ 144.944188][T15389] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 144.945934][T15389] RIP: 0010:uniform_split_supported+0x270/0x290 [ 144.947144][T15389] Code: ff 89 de e8 c2 20 ca ff 84 db 0f 85 47 fe ff ff e8 05 26 ca ff c6 05 f6 c2 22 06 01 90 48 c7 c7 18 44 fa 86 e8 31 2a ac ff 90 <0f> 0b 90 90 e9 24 fe ff ff e8 e2 25 ca ff 48 c7 c6 08 52 f7 86 48 [ 144.950897][T15389] RSP: 0018:ffffc90022813990 EFLAGS: 00010286 [ 144.952058][T15389] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8120ed77 [ 144.953559][T15389] RDX: ffff8881326f3880 RSI: ffffffff8120ed8a RDI: ffff8881326f3880 [ 144.955045][T15389] RBP: ffffea00062a0000 R08: 0000000000000001 R09: 0000000000000000 [ 144.956544][T15389] R10: 0000000000000000 R11: 0000000000000003 R12: 0000000000000001 [ 144.958043][T15389] R13: 0000000000000001 R14: ffff8881328b3951 R15: 0000000000000001 [ 144.959898][T15389] FS: 00007fb74cda4740(0000) GS:ffff888277b40000(0000) knlGS:0000000000000000 [ 144.961627][T15389] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 144.962886][T15389] CR2: 00007fb74ca00000 CR3: 000000013e072000 CR4: 0000000000750ef0 [ 144.964418][T15389] PKRU: 55555554 [ 144.965100][T15389] Call Trace: [ 144.965746][T15389] <TASK> [ 144.966331][T15389] ? uniform_split_supported+0x270/0x290