Re: [PATCH 7.2 v4 09/12] mm/truncate: use folio_split() in truncate_inode_partial_folio()

Zi Yan
2026-04-24T15:12:51Z

On 24 Apr 2026, at 11:07, Zi Yan wrote:

> On 24 Apr 2026, at 8:54, David Hildenbrand (Arm) wrote:
>
>> On 4/24/26 04:49, Zi Yan wrote:
>>> After READ_ONLY_THP_FOR_FS is removed, FS either supports large folio or
>>> not. folio_split() can be used on a FS with large folio support without
>>> worrying about getting a THP on a FS without large folio support.
>>>
>>> When READ_ONLY_THP_FOR_FS was present, a PMD large pagecache folio can
>>> appear in a FS without large folio support after khugepaged or
>>> madvise(MADV_COLLAPSE) creates it. During truncate_inode_partial_folio(),
>>> such a PMD large pagecache folio is split and if the FS does not support
>>> large folio, it needs to be split to order-0 ones and could not be split
>>> non uniformly to ones with various orders. try_folio_split_to_order() was
>>> added to handle this situation by checking folio_check_splittable(...,
>>> SPLIT_TYPE_NON_UNIFORM) to detect if the large folio is created due to
>>> READ_ONLY_THP_FOR_FS and the FS does not support large folio. Now
>>> READ_ONLY_THP_FOR_FS is removed, all large pagecache folios are created
>>> with FSes supporting large folio, this function is no longer needed and all
>>> large pagecache folios can be split non uniformly.
>>
>> In general looks good. Just one question:
>>
>> folio_check_splittable() also rejects SPLIT_TYPE_NON_UNIFORM / new_order for
>> swapcache pages.
>
> Since swapcache only supports PMD order or 0 order yet.
>
>>
>> It's confusing, but truncate would never stumble over such folios, correct?
>
> Right.

BTW, sashiko had a similar question when it reviewed v2[1]. It also complained
about when the split fails, the entire folio remains in memory. But that is the
consequence of failed split, unless we want to keep retrying the split.

[1] https://sashiko.dev/#/patchset/20260413192030.3275825-1-ziy%40nvidia.com?part=9

Best Regards,
Yan, Zi