Re: [PATCH RESEND v3 6/9] mm/truncate: use folio_split() for truncate operation.

[Zi Yan <ziy@nvidia.com>]

On 10 Dec 2024, at 15:41, Zi Yan wrote:

> On 10 Dec 2024, at 15:12, David Hildenbrand wrote:
>
>> On 05.12.24 01:18, Zi Yan wrote:
>>> Instead of splitting the large folio uniformly during truncation, use
>>> buddy allocator like split at the start of truncation range to minimize
>>> the number of resulting folios.
>>>
>>> For example, to truncate a order-4 folio
>>> [0, 1, 2, 3, 4, 5, ..., 15]
>>> between [3, 10] (inclusive), folio_split() splits the folio to
>>> [0,1], [2], [3], [4..7], [8..15] and [3], [4..7] can be dropped and
>>> [8..15] is kept with zeros in [8..10].
>>
>> But isn't that making things worse that they are today? Imagine fallocate() on a shmem file where we won't be freeing memory?
>
> You mean [8..10] are kept? Yes, it is worse. And the solution would be
> split at both 3 and 10. For now folio_split() returns -EINVAL for
> shmem mappings, but that means I have a bug in this patch. The newly added
> split_folio_at() needs to retry uniform split if buddy allocator like
> split returns with -EINVAL, otherwise, shmem truncate will no longer
> split folios after this patch.
>
> Thank you for checking the patch. I will fix it in the next version.

I am going to add two functions: split_huge_page_supported(folio, new_order)
and folio_split_support(folio, new_order) to perform the order and folio->mapping
checks at the beginning of __folio_split(). So truncate and other potential
callers can make the right function call.


Best Regards,
Yan, Zi